×Закрыть

Как получать удовольствие от работы (программирования)?

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

LinkedIn

Лучшие комментарии пропустить

Лучший способ получать удовольствие от того что делаешь — это делать то, от чего получаешь удовольствие.

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

Самый простой способ — это выработка условного рефлекса. Напедалил класс — съел аскорбинку.

Сначала они говорят, что программисту не нужна математика. Потом они говорят, что и всё остальное программисту не нужно. Потом они говорят, что и из программирования надо знать только то, что приносит деньги.

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

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

из-за новизны.
не обязательно чувство исчезнет. но притупится — стопудов

рекомендуется посмотреть всем кому за30

він взагалі для тих кому ще за 20, щоб знати що їх чекатиме... інші вже бачать це навколо :))

Начало неплохое, надо досмотреть, чего же этот гад скажет, чего не знаю уже я:-)

для себя я выделил фазы карьеры программиста в отдельно взятой организации(проекте)

1. обучение, изучение существующего кода и технологий
2. разработка чего-то нового, полезного и стоящего
3. стагнация. меньше разработки , больше багофиксов и разгребания текущих мелких проблем
4. упадок. на работу ходишь просто чтобы отметиться что побывал там, ибо знаешь что ничего интересно тебя там не ждет (см пункт 3)
5. увольнение

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

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

но все же 1-5 — не совсем стандарт.

есть два подхода к организации людей в проекте:
по ответственности «за участок».
по специализации, «конвейер».

если команда организована по первому способу, то 1-3 выполняется чаще в цикле, и реже выходит на 4-5, чем при конвейерном.

2. разработка чего-то нового, полезного и стоящего
3. стагнация. меньше разработки , больше багофиксов и разгребания текущих мелких проблем
А почему это именно этапы? Почему 2 исчезает, а 3 не наступает сразу?

может и сразу конечно 3ий, легаси-код никто не отменял :)

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

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

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

Если не доставляет удовольствия нужно расслабиться и пойти работать, например, заправщиком на азс и желательно зимой

Ты голимый совок с такими советами. Откуда вы вообще все такие беретёсь?
Это как раз о тебе написали: dou.ua/...c/10846/#527102

Угу, по мотивам старого-доброго демотиватора — demotivation.me/...kl5iwr0eeul.jpg Ось тільки особисто я їх в шахти не гнав, так само як і працівників АЗС не змушую взимку морозити дупи. Чо уж там, хай йдуть в офіс найближчого лідеру ринку (тм) та готуються підставляти мізки під товстезний х** кастомера, я ж не проти. Не хочуть ( / не можуть)? Ну так тоді чиї це проблеми?

Сначала они говорят, что программисту не нужна математика. Потом они говорят, что и всё остальное программисту не нужно. Потом они говорят, что и из программирования надо знать только то, что приносит деньги.

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

математика везде нужна, но в разной степени :)

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

Да, вам вряд ли каждый день нужна теорема о причёсывании ежа или Тьюринг-полные муравьи (теория хаоса в вашем террариуме, только сегодня и только сейчас!), но уж удовольствие от понимания шутки точно лишним не будет.

Тут вопрос приоритетов — интересного много, но на всё жизни не хватит и приходится выбирать.

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

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

Математику можно считать как раз смежной областью :)

Девять из десяти комментаторов данного форума так явно не считают. Хотя я согласен, конечно.

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

Глядишь — и интерфейсы получше будут, и LSP нарушаться перестанет.

Для проактивного, нужно решить два вопроса:
1. Ты хочешь быть большим в маленьком проекте, или маленьким — в большом
2. Ты хочешь все усложняющиеся задачи, «революции», или хочешь роста дохода на однотипных, «эволюции»

ошибка в ответе на любой из них — когда рацио не угадало психею, приведет к неудовольствию от работы.

Хочу много денег и на Багамы.

а при чем тут тогда хотелки денег и багам?

При том, что у Вас очень ограниченый перечень вопросов

перечисление всех островов планеты Земля было бы долгим.

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

несчастные же и на Багамах кончают жизнь самоубийствами.
и с деньгами тоже.

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

как вы хотите Багам, так вы на них побываете.
а раз не побываете то значит и не хотели.

в начале у меня подсказка была — для проактивных.

итак, если вы проактивная — то когда уезжаете на Багамы?
а если пассивная — то пост был не для вас

Противоположностью проактивности психики является реактивность, а не пассивность.

Это не айтишником нужно быть.

все просто, приходишь на работу и получаешь удовольствие

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

подработки в виде разгрузки вагонов с бочками с карбидом
не дают ни профессионального, ни карьерного и роста, независимо от того, что лезет в голову, ибо физ.труд. Однако, даже в этом случае, при срыве спины при разгрузке всякая фигня всё-равно начнёт лезть в голову, ибо нормально работать с больной спиной нереально. Так и с мозгом — если ему скучно и неинтересно (он, например, болен), его надо заставлять думать насильно, ибо только результат его труда приносит людям интеллектуального труда деньги.
Если очень нужны деньги, можно ебашить где угодно, забив на честь/совесть/престижность/законность/здоровье/кайфовость/мораль (нужное подчеркнуть). Однако если хочешь не только денег, надо что-то большее.
Иногда приходится выживать, но когда перешагнул этот этап — потребности качественно возрастают. По-крайней мере (ох не люблю я эти спорные американские теории) это утверждает Маслоу в своей пирамиде потребностей...
Почему-то в других профессиях ножничное количество таких личностей, что считают что работа всегда должна приносить кайф, а не просто приносить деньги?
Про самые яркие экземпляры ещё говорят, что «человек не на своём месте». Если человека не удовлетворяет работа и результат его труда, если работа не приносит удовольствия — он становится циничным, озлобленным, впадает в депрессию, начинает некачественно или очень медленно выполнять свои прямые обязанности и т.д. Есть, конечно, и чисто механическая работа, но тут уж «кто на что учился».
P.S. Но с психологической точки зрения Ваш пост лечебный =) Когда очень нужны были деньги, не думала об удовольствии, о престижности, о профессиональном росте... Не до этого как-то было. Иногда работа — это просто работа. А программистам повезло, они могут позволить себе покапризничать =)
они могут позволить себе покапризничать =)
Ой, ли?
работа всегда должна приносить кайф, а на просто приносить деньги
Просто работа программиста (по крайней мере в теории) сильно отличается от разгрузки бочек с карбидом.

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

А получать удовольствие от работы не всегда но за большие деньги, но зато, например, больше путешествовать нет ? Или у Вас жизнь и работа это одно и тоже ? Ближе к старости Вы будите у умилением вспоминать и рассказывать как вы классно кодили :)

А это принципиально к какой цифре ? что то изменится если вместо 70 написать, например, 50 ?

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

У каждого свой путь, кому то есть что рассказывать, кому то нету.

Я всегда готов послушать о правильном пути.

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

Я бы рад, так организм слишком живуч.

Ты же наоборот пишешь, что уже все: холистерин, сахар.

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

Ну да, но горы двигать и next gen AI изобретать что бы детям/внукам потом рассказывать энергии вроде уже нету?

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

«Больше путешествовать» относится скорее не к деньгам, а к свободному времени.

И, кстати, одно другому не мешает.

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

ну такая аналогия приводится часто :)

Думаю, не надо напоминать про аналогии и доказательсва (пусть обоснования).

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

это бред, типа: чашка кофе — черная дыра

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

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

Наследования чего?

Есть известная загадка: «Что общего между вороном и письменным столом?» И есть даже целый клубы, которые пытаются ее решить. Вот там самое логичное блискать своими аналогиями и ассоциациями.

Да, это отличная загадка. Но за неё вроде бы не платят?

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

Когда мне становится скучно и не интересно я вспоминаю как работал подсобником на стройке за 150грн/день и настроение сразу поднимается. Плюс ко всему, есть куча знакомых которые работают по 12 часов в день с одним выходным за 2к грн...

о да... равняться на беднейшие слои населения, правильной дорогой идешь...

у нас крім як в містах мільйонниках, середнього класу то і немає... а з поправкою, що в ІТ справжні мажори не ідуть, то з біднішого класу практично всі і вийшли.
а от про верхній, корупційно-олігархічний клас... ну та, можна попасти, з бізнесом, чи купити посаду, але шансів не більше 1%, тому сенсу на них рівнятись?

равнятся нужно на богатые страны или так и будем сидеть в повальной нищете и коррупции

Хватает исключительно мотивации — и слава богу, завидую, как и qwertysmerty;)
Лично я предпочитаю захватывать других уровней пирамиды Маслоу — так и работаю лучше, и живу поинтересней.

Почему-то в других технических профессиях ничтожное количество таких личностей, что считают что работа всегда должна приносить кайф, а на просто приносить деньги ?
Ну им не повезло с профессией/призванием, их жизнь наполнена унылыми 8-часовыми сменами, а у программистов есть возможность наполнить жизнь кайфом.

Программист — творит, грузчик — носит. Это огромная разница

Гы Каждый формошлеп мнит что от ТВОРИТ . Как по мне, у сантехника более творческая работа чем у программиста. Правда есть индивидуумы которые действительно «творят» (вернее тварят от слова тварь). :)

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

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

Хотите заставить проктолога заплакать? Спросите — кем он мечтал стать в детстве

Он ответит — шахтёром. Тогда я отвечу — мужик, ты в целом реализовал свою мечту.

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

Вы со строителями лично знакомы ?

С отцом своим, например, да, хорошо знаком, как ни странно. Было даже два периода времени когда сам работал на стройке: подсобником и инженером ПТО. Исключительно ради денег работал, но не все мои коллеги работали так.

А мне просто нравится кодить! Получал много, но почти всегда деньги вкладывались во что-то и их почти всегда не было в избытке. Очень трудно себя заставить работать, когда знаешь, что у тебя есть запас на несколько лет... Скорее всего ваш доход намного превосходит ваши потребности. Попробуйте отдавать деньги другим. Мы, например, раздавали друзьям, которым нужна была помощь в тот момент. У нас с женой даже была проблема — «избавиться от денег» — это когда мы деньги выделили, а отдать некому... Найдите ребёнка больного раком или чем-то другим и поставьте себе цель — довести проблему до решения. Начинаешь больше ценить жизнь, когда побываешь в онко-больницах — лежал с малым полгода... Лысые девчонки 4х лет клеят на голову верёвочки и со словами «У нас есть красивые косы — идём к нашим принцам» ходят по отделению. Трудно не плакать. Посмотрите вокруг — полно людей, которым можно помочь и, возможно, спасти жизнь.

Нет, с деньгами у меня мало получается, не часто работаю последним временем. Но и потребности малые. Скорее проблема в том. что не тянет к вебу, по крайней мере тому который я вижу — «нужно исправить модуль Wordpress, сверстать формочку под Joomla,...». Да, можно доучить пхп и мидлом работать, но там опять же — «валидная верстка, работа с CMS» всюду встречаются. На данный момент курс выбран на изучение Java, что мне очень и нравится, по крайней мере сейчас :) Правда тут отговаривали, но пожалуй лучше еще пол года поживу при малых потребностях, и поучу ее(параллельно выполняя мелкие пхп задачи), чем буду ломать голову всякими пехопе вакансиями с комбайн требованиями.

То что вы делаете — это прекрасно. Главное чтобы люди наглеть не начинали. Лучше всего отдавать больным детям, ну и, так как ситуация в стране такая — на лечение воинов АТО.

Люди, работающие в гугле и знающие Java мне говорили, что стоит изучать Python. Правда, когда я спросил «Это потому что вы уже знаете Java?» — человек улыбнулся и промолчал... Так что я сделал для себя вывод и то, и другое сейчас стоит изучать. Мой язык сейчас — PHP. Начинал с перла. Смотрю в строну node.js и фронтэнд разработки. Ни питон, ни джава пока не цепляют.

Я много гуглил различных рейтингов, и везде Java самый перспективный язык для изучения. Ну и Python конечно в топе, и набирает обороты. PHP на 6 позиции где то. Но он выше уже не поднимется — конкуренты появились очень сильные, и лучшие. А вообще — надо смотреть не на то чтобы язык был выше всех, а чтобы он нравился. Если не нравится — далеко не заедешь, не изучишь его вдоль и поперек, и не станешь мидлом-сеньером.

Перспективный? Да, для работы над очередными «формочками» за бОльшие деньги.
Интересный? Отнюдь нет.
Люди из гугла правы — лучше учить другой язык.
Если Java нравится — то рассматривайте её как одну из ступенек на пути к получению удовольствия. Будет проще «соскочить», когда поймёте окружающую картину.

Я б не советовал. Джава, как и дотнет — это огромные монстры для изучения. Через полгода знать не будете. Вам понадобится 5 лет работы и обучения, чтобы придти в себя, и потом и далее новые библиотеки, новые фреймворки.

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

Правда, дело и не в языке. С джавы можете переключиться и на Scala. И на джаве не только формочки, если хорошо искать.
Но просто предупреждаю — это черная дыра по времени, вы не представляете, во что ввязываетесь. Если начинать, то лучше выбрать что-то другое, попроще. Тот же питон вроде как проще, но не менее прибыльно и интересно. По слухам, я не знаю. Я по дотнету больше

Вам понадобится 5 лет работы и обучения, чтобы придти в себя
хз як про джаву, а от з дотнетом в декілька раз промахнулись :))

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

Проблема нашей индустрии
якої саме індустрії?
в аутсорсі з тим все досить добре, в продуктових — теж ніби стараються, а в не ІТшні контори як до вас — справді не кожен піде, не кажуче про їх коллекторський напрямок (моральний фільтр відкине ще 70% кандидатів)
включая книги по мастерству кодирования
ага, бачив я таких, теоретиків від програмування... можуть годинами дискутувати про правильність застосування паттерну в 10 рядків коду, і про чистоту його підходу в цій системі... замість того щоб зробити щось корисне.
якої саме індустрії?
Взагалі програмування. З кадрами проблеми. Ніде з цим не досить добре.

Щоб не бути голословним, що потрібно для дотнета і в якій послідовності:
Эндрю Троелсен «Язык программирования C#»
1311 сторінок.
Джефрі Ріхтер «CLR via C#. Программирование на платформе Microsoft .NET»
896 сторінок. Цю книгу потрібно знати на пам’ять. Читати декілька разів.

Це тільки книги по мові і платформі. Ви ще взагалі не програміст. Самої мови недостатньо.
Далі необхідно вивчити реляційні бази данних, добре знати SQL, і проектування баз даних. Практично не буває роботи, де б не використовували бази даних, а реляційні — стандарт. Та й проектувати необхідно починати вчитись з баз даних.
Тут може бути різний об’єм в залежності від глибини. Не менше ще 500 сторінок.

WCF ~ 500 сторінок.
На чому буде кліент?
ASP.NET ~ 1500 сторінок.
ASP.NET MVC ~ 800 сторінок.

JavaScript, JQuery, CSS. Кожна 400-1000.
Ще деякі бібліотеки для кліента.

Якщо ж десктоп, то WPF ~ 1000 сторінок. І по всьому видно, що скоро ніхто питати не буде, хочеш ти писати для десктоп чи ні. Це теж потрібно буде знати.

Це все тільки потрібні конкретні знання для дотнета.
Фаулер «Рефакторинг» — обов’язково
Банда чотирьох «Патерни проектування» — обов’язково.
Щось з Фаулера по UML — обов’язково.
Кент Бек TDD — обов’язково.
Ерік Еванс DDD — бажано.
Макконел «Совершенный код» — бажано.
Тут ряд можна продовжити, є багато цікавих і корисних кних.

Бажано вивчити якусь функціональну мову програмування, це змінює погляди не код і стиль.

Як ви думаєте, я помилився в декілька разів в більшу сторону, коли написав — мінімум 5 років? Ці книги не тільки прочитати потрібно, а й набирати досвід, використовуючи ці знання.

Про те, що є теоретики, які нічого не роблять: так і не потрібно вибирати з двух зол. Дуже багато програмістів, які пишуть впевнено весь перелік знань в резюме, але думають, що вони знають достатньо на рівні: «я працював в проекті і бачив як Вася писав код по цій технології. Там немає в чому розбиратись».
Відкидаємо такий варіант, правда? Хочете щось знати, потрібно це вчити спеціально.

знаєте в чому проблема вашої теорії? ви з тих самих теоретиків :)))

якщо братись за книжки — весь дотнет, з усіма майкрософтівськими частинами фреймворку — в Professional C# Wrox’а, всього в 1600 стор в останній редакції.
читати — лише те що треба зараз, і то не сильно допоможе.

як думаєте, хто вам більше користі і менше шкоди на проекті принесе, той хто прочитав 10 книжок на 5к сторінок, чи той хто рік працював на аналогічному проекті, під керівництвом васі, де його пару раз били по руках за «творчість» і показували що і як можна роботи, і що — ні, в загальному згадуючи чому?

це все — при однаковій наполегливості, адекватності, і вмінні гуглити :))

п.с. розповідь суті книжки на 100-300 стор, з привязкою до поточного проекту займе декілька годин, в результаті людина не буде здатна пройти співбесіду в теоретика як ви, але зможе еффективно використовувати це на проекті, що в випадку читання книжки — не факт, а то і шкода буде, як почне всюди тикати зайве

Я перерахував книги, які дають глибокі знання не якихось сторонніх бібліотек. Чи ви патерни, чи Фаулера будете читати, коли стане потрібний? Тоді ці книги ніколи не стануть потрібними, ви й знати не будете, наскільки у вас код поганий.

Ці книги дають фундаментальні знання по дотнету, без яких не можна себе називати програмістом на дотнеті, чи знання основних технологій. Або дають знання, як потрібно писати код. Хоча б розуміння, які бувають методики.

З таким підходом, щодо вміння гуглити — наймайте на роботу програміста сантехніків, двірників. Погуглять.

І не потрібно ділити програмістів на теоретиків і практиків. Це така робота его, людина якщо щось не може, то починає просто так вважати себе кращою за інших. При однакових умовах, той, хто прочитав книги, має більші шанси писати краще код. Ви ж тупішим не станете, якщо книгу прочитаєте? Тому, хто читає книги, не забороняють займатись практикою. І навпаки, вам, любителю практики, ніхто не забороняє поглиблювати знання.

ви й знати не будете, наскільки у вас код поганий.
немає «поганого» чи «хорошого» коду, цей мем придумали теоретики.
функціонально він є робочим і не робочим, по корисності — швидкість вїзжання в нього, якщо він виявився частково неробочим, щоб це пофіксати.
оверюз паттернів теоретиками останне(швидкість вїзджання) доводять до такого, що простіше все викинути і переписати, от тільки ще ті ж паттерни заникують так глибоко в систему, що їх випилювати звідти ще довше, ніж дебагати те що є...

Тобто ви пишете, що не буває поганого коду, а далі перераховуєте, коли він буде поганий? (оверюз паттернів наприклад)

Не оверюзайте патерни. Взагалі, щоб не любити патерни, потрібно їх знати. А то якось не чесно. У мене знайома казала, що не любить анекдоти. А потім виявилось, що вона просто не розуміє смисл. ))

Патерни потрібні просто щоб їх знати і в крайньому випадку, якщо без них ніяк, то застосовувати. А взагалі, це мова програмістів. Ви, коли спілкуєтесь з іншими програмістами, будете знаходити швидше взаєморозуміння, якщо знаєте загально прийняті терміни. Це ж стосується UML. Саме по собі зло, але інколи потрібно.

Тобто ви пишете, що не буває поганого коду, а далі перераховуєте, коли він буде поганий? (оверюз паттернів наприклад)
він не є від того «поганим» :)))
якщо він написани в індус стилі, +10 паттернів на 5 функцій, але бронебійний, і нікому не треба залазити в нього — він має позитивну загальну оцінку. не існує шкали «о, я помітив тут це — це отстой, викинь і перепиши».
Взагалі, щоб не любити патерни, потрібно їх знати.
я за весь час від них бачив приблизно однаково шкоди та користі.. причому останне зазвичай починалось з слів «я тільки що прочитав чудову книжку... треба заюзати, нам якраз підходить!».. а перше — от тут юзаєм це, я/замовник так сказав — погугли, що це
А взагалі, це мова програмістів. Ви, коли спілкуєтесь з іншими програмістами, будете знаходити швидше взаєморозуміння, якщо знаєте загально прийняті терміни.
і відповідь з історії:

Faulkner: «[Hemingway] has never been known to use a word that might send a reader to the dictionary.»
Hemingway: «Poor Faulkner. Does he really think big emotions come from big words?»
Джава, как и дотнет — это огромные монстры для изучения.

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

человек учивший программирование по паскалю может написать паскальную программу на любом языке !

В оригинале это, по-моему, про Бэйсик.

Чем вас не устраивает современный Паскаль?

По-моему, любые мэйнстрим-языки, это такие монстры
багато пробували, чи все по перенесенню досвіду з пхп ? :))

За 20+ лет разработки PHP 3 стал лишь седьмым (если не считать языки СУБД и разметки и стилизации текста) по счету языком, на котором писались коммерческие приложения. Сейчас в процессе изучения C# (одиннадцатый) и почти готово кроссплатформенное (Windows и Linux) многопроцессное приложение по синхронизации БД несколько разных приложений на разных платформах, языках и СУБД. Изучать C# и .Net начал пару недель назад. Ничего особо нового в них не обнаружил — читаю код и примерно представляю как он будет выглядеть на Си или Ассемблере, какие функции ядра будут дергаться. По сравнению с, например, метапрограммированием на Ruby — всё однозначно понятно. Больше всего боялся атрибутов, но не так страшен чёрт как его малюют — оказывается обычная рефлексия, даже проще чем работа с аннотациями на том же PHP.

По сравнению с, например, метапрограммированием на Ruby
сам подумываю серьезно заняться Ruby, возможно вообще с переходом на Рельсы.
как раз из-за метапрограммирования (ну и DSLщины принятой в руби-мире)

Интересно было бы услышать ваше личное впечатление.

Сейчас в процессе изучения C#
как язык — мне понравился. использовал его до изучения и перехода на Java.
но, узковат, в силу разных причин, мир .NETа, в сравнении с планетой JVM

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

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

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

Экстремальные программисты, по-моему. :) Не в методологическом смысле, а по жизни. Сознательно (надеюсь) идут на риск завязнуть, ради установления рекорда :)

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

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

Я не пожалел, что изучал руби, рельсы и т . п. — полезный опыт, — но вот желания использовать в продакшене не возникло.

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

Изучать C# и .Net начал пару недель назад. Ничего особо нового в них не обнаружил — читаю код и примерно представляю как он будет выглядеть на Си или Ассемблере, какие функции ядра будут дергаться.
ну ну :)))
успіхів з добираням до першого великого проекту, про ассемблер і функції ядра там і близько не пахнутиме ;)

Подозреваю, что типовые мои задачи (этот синхронизатор все же не типовая и скорее как учебный проект, закрепляющий знания синтаксиса и особенностей низкоуровневых библиотек) будут решаться в рамках хорошо знакомых мне парадигм, паттернов и т. п., таких как ООП, ФП, MVC, ORM и т. п.

И да и нет. Есть языки, совсем не похожие. Просто так с паскаля не перепрыгнуть.

Потом, в общем идея верная, что близкие языки можно быстро освоить, кругом циклы, ветвления. Но это смотря как освоить. Если на уровне студента писать, и считать, что изучив основы, вы можете теоретически написать сложный проект, то можете останавливаться. Если же работать реально, за деньги, то тут встанет вопрос вашей производительности и качества кода. Зачем вам с уровнем студента платить даже 500 долларов в месяц, если Коля всего за 4000 тыс долларов работает в 28 раз эффективнее?
А языки, даже близкие, имеют некоторые небольшие отличия, которые резко меняют стиль и эфективность работы с языком зависит от того, как его используете. Будете любой язык превращать в паскаль — хорошего ничего не выйдет.

И действительно, не в самом языке дело. C# всего со всеми подробностями 1300 страниц где-то. Много, но вполне подъемно.
Но фокус в том, что не единым языком и велосипедами живы.

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

Не спорю, что есть языки очень сильно отличающиеся и веб-сервер на FORTH будет сильно отличаться от веб-сервера на Haskell, но (не знаю к сожалению или к счастью) в мэйнстриме языки довольно похожие по основным парадигмам, грубо говоря, похожие так или иначе на «Си с классами».

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

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

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

разделение на фронт и бек енды есть в нормальных языках. Вот в вакансиях джавы например редко встречается в обязательных требованиях знать верстать. А пых кодеров держат за быдло

Разделение не в языках, разделение в головах у менеджмента.

Всегда удивляли люди, которые находят верстку... хренью. Как по-мне писать на PHP гораздо грустнее, чем просто верстать сайт.

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

Задам еще один вопрос (танцанем от печки). А что ты хочешь, что тебе приносит удовольствие от работы?

На данный момент приносит удовольствие изучение Java. Будем надеяться что не пропадет.

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

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

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

Никак. Потому что жизнь — это боль.

А как можно не получать удовольствия от программирования?

Інколи дійсно, задоволення близьке до статевого.

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

А от каждого бага — рождается. В итоге и багов нет)

Это ты намекаешь что за каждый баг е*ут :)

Котят уже прибили?;)

я люблю котят, а вот людей не особо

В смысле чем больше накодите, тем больше погибнет? Вы до того как стать программистом в наверное Освенциме работали :)

Не, скорее просто недавно «Тетрадь смерти» просмотрел и вставило))

Вот сейчас и я поною! ЗЫ: ух, какого Вы древнего динозавра откопали :) . тут все проще- я не люблю работать с живыми людьми. Пара вынужденных часов на саппорте и я готова бить людей ногами и топить в кислоте. Но это не самое страшное. Пик моих чувств наступает после фразы :"Я тут решил, что надо внести поравочки..." хотя до этого все было ок и ты же сам хотел именно так. И когда убеждали, что это гауно- никто не слушал. А еще меня особенно радует фраза :" Вы что, не можете сделать это КРАСИВО?!" И «красиво» никак не желает описывать. И ты такой сидишь и гадаешь, как же это «красиво». и все твое «красиво» недостаточно «красиво», как и зеленый -недостаточно зеленый.. А на наводящие вопросы всегда один и тот же ответ, ну Вы поняли какой. Когда нет людей, а с тебя требуют исправление какой-то сурьезной баги на бекенде (а у Вас знания аще из другого болота), и бегают к тебе каждые 2 минуты с вопросом :" Ну как там, исправили?" А ты такой сидишь и думаешь :" блин ,я же всего-лишь qa, за что мне все это?!"
Я ща вот тоже от своей работы удовольствие почти не получаю. Вот и отрываюсь как могу.
И да, я понимаю что нужно что-то срочно менять в этом всем.

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

Хз, меня в свое время очень перло

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

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

Я до 45 с большим интересом программировал. А потом, сил стало сильно меньше, не получается, как в 30-35 с горящими глазами делать что-то. Да и со здоровьем не так, как в 30 и сахар повышен и холестерин и вообще чувствуешь не так, как 10 лет назад.
Хочется сейчас относительно спокойствия, чтобы кто-то пинал, четко говорил, что делать, а я уж не спеша в стиле «старый конь борозды не портит». Но такого в нашей области, как я понял нет. Нужно самому за интересные задачи зубами хвататься и бабло выбивать.

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

Ну да надо было больше за компом сидеть. Я же, дурак наоборот делал. По выходным на велике, на работу с работы на велике.
До 35 в выходные до усталости 140-150 км надо было по грунтовкам, до 44 в выходные до усталости 70-80, до 44 наработу и с работы 21 км тула и обратно на средней 28 и отдохнувший, только вспотевший приезлал (было решение помыться). А вот в 44 резко сил не стало и теперь до усталости 30, максимум 40 могу.

Ну велоспорт это тот еще способ гармоничного развития организма.

Это был сарказм? Вроде как велосипед даже лучше бега

Чем лучше? Изолированная монотонная мышечная нагрузка с упором на сердце.

А ты по пересеченке и никакой монотонности.

Зависит с чем сравнивать, если с жимом штанги от груди или кикбоксингом, то все равно нагрузка монотонна и аэробна.

Железо очень опасное. Есть риск словить нездоровье. Потому не вижу смысла для себя таким заниматься. Программисту главное много двигаться. Велик отлично с этим справляется. У меня иногда давление подымается(связано с нервами), а когда проедусь то сразу ок чувствую себя.

Смешно, а с велика упасть можно.

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

быстрее при беге упадешь чем с велика. А особенно если живешь в цивилизации с нормальными дорогами)

Удивительно спорное утверждение.

что мне теперь начинать ссылочную войну?) гугл в руки

Ну или нету в гугле никаких ссылок, а ты балаболишь.

mensbook.ru/...velosipede.html

Одна из многих

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

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

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

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

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

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

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

а как еще назвать подкапывание к словам. Смысл понятен.
очередные фантазии

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

А ты уже выложил свой репрезентативный опыт в интернете, перед тем как меня в гугл посылать?

И именно такая нагрузка тренирует и развивает сердце и крупные мышцы, я не говорю о спортсменах.

НУ в велоспорте развиваются 2-е мышцы, и как я уже написал это не гармоничное развитие, это изолированная, монотонная, аэробная нагрузка. Занимаясь например кикбоксингом, развивается намного больше груп мышч, аэробная нагрузка комбинируется с анаэробной.

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

Интересно посмотреть на ресурсы которые говорят что на велике задействуются «все мышцы».

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

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

А ты на програмеров посмотри.

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

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

парочка мышч ног

а еще на животе и т.д.

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

Что сарказм? Что я так катал? Я так катал, пока моложе был. А вот после 45 уже никак так не покатаешь. Да, некоторым везет и до 70 могут, но некоторые и до 120 живут.

Велоспортом я не занимался, просто на покатушки ездил с народом в poehali.net. Не помог в 47 огурчиком быть и сахар повышен и холестерин при весе 94 и росте 192.

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

Абсолютный бред. Каденс должен быть достаточно высокий, такой, чтобы на педали почти не давить. Иначе смерть коленям.
Что слишком. Слишком это 250 по грунтовкам от Сморгони до Столбцов через Налибоки (есть такой маршрут на Poehali.net) — это слишком.
А 150, если жидкости пьешь достаточно — это так, до усталости. 80-100 — это прогулка.

З.Ы. В 42 в инфарктном лежал, по скорой положи, сердце проверили — в очень хорошем состоянии было. Попал из-за стресса.

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

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

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

А митинги — это да — любимое развлечение «эффективных менеджеров». Нет, митимнги нужны, но по мере необходимости и как можно краче.

как любой начинающий
Вот только не многие готовы видеть юниора в 40. Почему-то 25 летние считают (выучив 2-3 фраймворка в лучшем случае за 7 лет), что 40-летние новый фраймворк за 5 мин могут изучить.
Почему-то 25 летние считают ... что 40-летние новый фраймворк за 5 мин могут изучить.
150%! я сам только недавно отрефлексировал этот источник пораженческих настроений: ожидания других что раз у тебя за 20 лет стажа — то фрейморки в голову укладываться должны беглым скроллингом содержания доки. вместе с нюансами, которые можно только либо прочесть на форуме разработчиков, либо побившись о них головой.
на днях вот — докопался что баг не у меня. придумал исправление в core, написал авторам тикет, с вариантом исправления. ответ — а-а-а, да, мы знаем. у нас даже в доке, на странице такой-то есть намек, в сносках. и для вот такого юз-кейса как у вас предусмотрена вот такая функция. дерните ее, перед вашим кодом — и все будет хорошо.
и таки да, пару часов поиска, часик на придумывание обхода, часик переписки, и аж целый Один нюанс фреймворка постиг! :)
Отношу это к депрессии и похоже это из-за нее, жру прописанные антидепрессанты врачебными дозами.
это да :) в утешение нам, 40+ - америка и европа тоже иж жрут массово :)
Садишься и делаешь, красиво, чтобы от того же, что красиво написал удовольствие получать.
да, это один из моментов, который доставляет удовольствие, хоть уж и сколько кода не понаписано :)

Как ранее верно подметил Виктор, ты

Вероятнее всего ты не QA, а «швец, жнец и на дуду игрец»
. И с таким спектром задач достаточно сложно справляться, особенно если они на тебя сваливаются внезапно: вчера ты QA, а сегодня QA, дизайнер, девелопер, ПМ и т.д. Но, если ты с этими задачами справишься, пусть не сразу, постепенно, обращаясь за помощью и советами к другим, то это очень пригодится в будущем.

Скажу по своему опыту, мне таким вот «мастером на все руки» (разработчик, тестер, админ и немножко тимлид) пришлось поработать где-то года 3, хотя даже чуть больше.
И сейчас я легко могу настроить себе отличный «dev environment» (настроить у себя web, smtp и прочие сервера, при надобности собрать небольшой кластер из виртуалок), который максимально будет соответствовать той среде, где моя программа будет работать.
Я буду писать код так, чтобы при разворачивании его на продакшн, людям которые это делают, было максимально просто и удобно (чтобы было достаточно поменять одну строку в конфиге и у тебя уже продакшн-сборка).
Побыв «тимлидом», пусть даже команды из 5 человек, я научился писать код так, чтобы он был практически идеален и другие старались писать так же.
Побывав на месте QA, тоже стараешься уже в голове прокрутить все возможные сценарии использования свой программы и написать ее со всевозможными проверками и т.п.

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

а можно просто варить борщ? :]

а можно просто варить борщ? :]
Конечно можно, но нужно стараться готовить идеальный борщ.

А, как говорится, чтобы идеально приготовить борщ, нужно думать как борщ :).

Вы что, не можете сделать это КРАСИВО?!"
Вы не представляете как я Вас понимаю. Я отработал почти 10 лет в полиграфии. Ситуации были разные. Но проблема в том, что сейчас вся отрасль глубоко просела. Работал дизайнером-верстальщиком (книги, журналы, газеты), препресс-дизайнером (допечатная подготовка по IT- классификации это близко к Senior). Фразы «Сделай красиво» и «Надо на вчера» в последнее время приводили в бешенство. Со временем как я подозреваю начал развиваться аутизм (в смысле с клиентами я норамально не мог общаться. По учению менеджеров: клиент— это священное животное которое типо приносит тебе деньги). Проблема бы была в том, что у каждого свои понятия красоты и свои представления промежутка времени «на вчера».
Как я говорил полиграфия очень просела поэтому берут любых клиентов. И все испражнения которые они приносят в своих файлах, выгребать должен именно препрессник с неопределенными понятиями о красоте и с полной прострацией во времени с определением «На вчера». Собственно есть пару веселых примеров так сказать из последнего, но не буду засорять эфир.
Сейчас пытаюсь войти в IT по позиции front end developer. Хотя мне было бы проще пойти по дизайнерскому направлению. Есть представление о типографике, модульных сетках, композиции, колористике. Граф. пакеты Photoshop, lllustrator, InDesign знакомы не по видео урокам. Но увы за 10 лет эстетических маразмов кажется их маразмов, уже наелся. И кстати это все очень влияет на психическое здоровье.

Тогда лучше в секс-индустрии работать. Миллиард человек гибнет за раз.

PS. А есть кто так код и пишет. Написал строчку недокументированного говнокода — и у корпоративного клиента 8000 человеко-часов как корова языком слизала.

Тогда лучше в секс-индустрии работать. Миллиард человек гибнет за раз.
не, ці джавісти таки збоченці...
уявив, як з «одного разу» народитись може більше 3х дітей, особливо сильно більше...
/facepalm

В один з моїх самих продуктивних днів я видалив близька тисячі рядків коду, замінивши їх на десять строк.

Не уверен пишете ли Вы тогда меньше строк или же наоборот.

Временно поставить себя в жесткие рамки, а потом, вернувшись обратно — вычесть разницу и начать ценить то, что есть. Энтузиазм, удовольствие.. идеально никогда не будет, ни в чем. Самое дотошное в работе программиста, имхо, на фоне огромной энергичности в молодом возрасте — сидеть и писать код, отлаживать его, думать, вместо того, чтобы жить в активном ритме в реальном мире без клавиатуры и компилятора. Прояви фантазию, придумай/найди/вспомни причину, ради которой стоит работать/кодить, и вперед. Если и в таком случае «не штырит» — то это либо лень, либо не твое. Мир не ограничен фреймворками, все в твоих руках, пробуй — и делай выводы самостоятельно.

А о чем вы думаете когда программируете?
«Капеееец, шо я делаю?? Я же космонавтом мечтал быть, какое нафиг „Exception Processing Message“?!! Ничегоооо! Сделаю работу, выгодно продам, и профит в копилку! Насобираю, инвестирую, потружусь, приумножу, инвестирую, bla bla bla, разбогатею, и полечу в качестве космического туриста, прямо как Ричард Аллен Гэрриот!! А то и свое космическое агентство запилю!!»

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

Надо зацикливаться не на процессе, а на результате.
Зацикливаться не нужно, вредно. Тут как и при написании программы: «определение целей» => «проектирование» => «реализация», а в свою очередь, «проектирование» делишь на еще меньшие пункты. Т.е.:
Может цель — устроиться работать в крутую компанию?
..очередной пункт из «проектирование».
Самое простое — ради денег.
Ради того, что ты взамен на них получишь. Деньги — ничто.

Facebook, VK, Wikipedia, Automattic (Wordpress), Badoo, Yahoo, Zend Tech — не большие ли? ;)

Вообщем, как я понял из советов, мне подойдет:
1. Остаться на PHP
2. Подтянуть знания PHP и back-end в общем(включая фреймворки)
2.1 В качестве фреймворка выбрать ZEND, так как он наиболее похож на Java, которая ориентирована на ООП программирование
3. Бросить фриланс и уйти на удаленку, либо в офис

2.1 как-то очень странно выглядит.

Так это вывод от моих предпочтений, а не правило для всех

Я про вот эту часть: «выбрать ZEND, так как он наиболее похож на Java, которая ориентирована на ООП программирование»

1) Java не ориентирована на объектно-ориентированное программирование программирование («бутерброд с маслом масляным бутербродным» :) Она является ООП-языком, как и PHP.

2) Zend Framework не похож на Java, он (и не только, некоторые другие тоже) похож на некоторые Java-фреймворки архитектурно.

В общем, учить PHP чтобы перейти на Java мне кажется несколько странным. Нужно ООП — в PHP оно есть вполне полноценный. Нужна Java — её и надо учить.

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

Обычно нужно не верстать, а быть способным поправить вёрстку. Обычно нужно не сложный фронт-енд писать, а поправить JS или прикрутить плагин.

Было бы хорошо. Но столько вакансий где пишут «валидная верстка», или вовсе HTML ставят выше PHP. Идти учиться верстать, или как...

Но столько вакансий где пишут «валидная верстка»
это да. в том и отличие миров разработки PHP и Java. phpисты — бОльшие универсалы :)
знакомый директор, небольшой фирмы, постоянно в поиске PHP программистов:
Джаве то мы научим, не проблема: пхписты хорошо знают то что редкий джавист знает — нюансы работы http, браузера, и html/css/js;

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

и вперед, искать работу

жирным плюсом будет если выберете REST сервер и напишите к нему хоть на qooxdoo Web UI. лучше на чем-то — AngularJS/Sencha Ext JS/Dojo

Вы не являетесь программистом, угадал?
Программирование — не цель, а средство и деньги не цель, а средство. В программирование нет романтики хакеров из телевизора.

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

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

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

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

В философском плане любая деятельность бессмысленна.

В программирование нет романтики хакеров из телевизора

Такая «романтика» никогда у меня позитива не вызывала, это школьничество

Вы не являетесь программистом, угадал?

Я Junior PHP Developer, как себя оцениваю сам, и как меня оценил более опытный PHP программист.

Вы хотели сказать в «аутсорсе»?

Нет. Я нигде кроме фриланса не работал

либо задач практически нет.

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

перелезть из front-end на бэкэнд

Я сижу в back-end, и никуда с этого направления переходить не хочу, ибо нравится

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

Я имел ввиду что нельзя взломать Пентагон через программу на Delphi или зеленый скринсейвер, получив 100500 нефти, свалить на Бали. Также программисты почему-то в большинстве своем не умеют ремонтировать телевизоры и утюги...бездельники одним словом.

мне кажется тут личности которые думают о взломе пентагона — не выползают) Они в школе сидят

Они уже повзрослели и организовывают стартапы.

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

Мой Вам совет. Пойти поработать в стартап.

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

Стартап, и лохотрон от некоторых товарищей которые заходят на ДОУ (мега крутые маркетологи с гениальной идеей) разные вещи. В нормальных стартапах нормально платят.

у меня стартап всегда ассоциировался с «создаем уникальный сайт, нужны люди, но так как это стартап, то оплаты не будет, проценты от будущих продаж»

не, это вы про лохотрон говорите, а не про стартап

Я працював у стартапі depositphotos.com. Гроші платили вчасно. Зараз працюю у стартапі в Швеції, з фірми мені зробили запрошення й допомогли з отриманням дозволу на роботу.

Нормальні стартапи мають інвестиції, з яких й платиться заробітна платня. Доречі, обидва стартапи починалися на PHP, потім ряд сервісів переносився на C++/Java.

Ну тоді, стартапи — це класно!)

А как обстоят дела с поиском работы для junior java developer? Через сколько месяцев после перехода с PHP, можно уже будет что то за деньги писать? Подозреваю что сначала придется в фрилансе побывать.

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

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

Плохи дела. Пожалуй надо будет еще пол года точно фрилансить на PHP

А чего вы ждете от Джавы, чего вам не хватает на пхп?
Или думаете, что как только поставите эклипс — то из-за занавески выбежит единорог?

Хорошо, опишу:
Новый язык — всегда интересно
Более развитый, упорядоченный, строгий(можно писать безопасные вещи)
Возможность работать в разных средах, выбирать куда идти
Более престижный(имхо), что тоже добавляет часть желания изучать
Более оплачиваемый
Проекты посерьезнее большинства что есть на PHP

А доказать свои высказывания можешь? Или это только на основе того, что тебе так кажется?

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

Упс. Круто, однако. Попросить обосновать свои высказывания и тут же тебе обозвали некультурным человеком.
Т.е. в твоем понимание культура — это писать ни чем не обоснованные высказывания?

Культура — это как минимум не тыкать незнакомому человеку.

shkolazhizni.ru/...hive/0/n-30874
За сим самовыпиливаюсь из этого сра.. обсуждения.

Все что вы перечислили, не имеет к реальности никакого отношения. Ну кроме того, что «новый язык — это интересно». Проблема только в том, что Джава — язык старый.

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

И да, если душа просит «фана», то посмотрите в сторону функциональных языков, или хотя бы js. Вот там будет действительно смена парадигмы, а не просто смена стрелочки на точку.

js я уже насмотрелся, когда приходилось скриптить веб морду, спасибо)

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

Нет, мне просто бек-енд ближе

Зачем, когда я могу юзать и PHP, и Java(если продолжу учить ее)

Я же говорю — если душа хочет фана и смены парадигмы.
Юзание Джавы на беке ни чем не отличается от пыхи.

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

Частично отличается — код красивее и строже
Заканчивайте нести ерунду, и посмотрите код фреймворков, типа симфони.

Я так Вам скажу. Есть идеальный мир. Он в книгах и в наших мыслях. В нём всегда идеальный код. Нет костылей, нет лапши, нет велосипедов, проекты продуманы от и до и новая фича не добавляется за один день. Но в реальном мире всё не так. Иногда немного не так, иногда — совсем не так. Ведь зачем мы что-то пишем? Чтобы создать новый товар/услугу и заработать на этом на жизнь. Никого (кроме программистов) не интересует красота кода. Всех интересует соответствие конечного продукта требованиям потребителя продукта. Красота кода при этом часто страдает. Такова реальность. Душа хочет красивостей, новых технолгий, строгой архитектуры. Я прекрасно Вас понимаю. А заказчик, к сожалению, не хочет потратить месяц на переделывание архитектуры для введения новой фичи. Заказчик хочет новую фичу максимум за неделю. Если фича будет очень хорошо видна (добавит нового контента или сильно улучшит интерфейс) — можно две недели.
Лучше осознайте и примите это сейчас. Или не идите в программирование. Максимум — пишите что-то для себя по вечерам. Иначе работа программиста может стать болью.

Хороший код так же способствует улучшению скорости разработки и уменьшению багов. Я никогда не буду индусом, который пишет как попало. Заказчики разные бывают — кому за 10 долларов написать движок, а кому нормальный проект должен быть. Вы же машину не только по цене выбираете, а и по качеству. Как и все остальное

А пока будете искать идеального заказчика — кушать что будете?

Буду делать то что есть. Но стремление к лучшему всегда должно быть.

От этого можно получать эстетическое удовольствие инженера;)

Ну если бы вы поработали над онлайн приложением, где поддержка ИЕ10+, может у вас бы изменилось мнение.

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

За счет асинхронности и отличного от пыхи подхода к ООП — язык очень интересный, особенно если заюзать на серверной части.

зачем? Я js не так долго изучал, чтобы выгоднее было на нем в бекенде сидеть, а не учить Java. Тем более что я же только скриптил работу с дум и аякс, и то на фреймворке jQuery

ну js на бекенде это зрелище не для слабонервных, зачем такие советы давать чтоб потом совсем у человека желание отбить?

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

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

А надо ли? Асинхронность обычно мало где нужна, весь back-end на PHP делается. Изучать можно все, но не лучше ли в одном стать профессионалом.

вот я бы на вашем месте не делал столь поспешных предположений

Асинхронность обычно мало где нужна
весь back-end на PHP делается.
уверены?

вы ещё не забыли, что мы говорим о том, что бы порадовать себя отличной от пхп парадигмой?

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

тогда лчуше советовать кложур/хаскель/ерланг

вот именно, ООП очень нравится

дык в самом начале и советовал :)

нет, нет, парадигма как раз устраивает. Вопрос о смене языка, чтобы чуть сменить обстановку, ну и как вариант — пойти в другую среду. Как вариант. Проблема в том что на PHP полно проектов по установке CMS, верстке, написании мелких скриптов(хотя тут может и не проблема вовсе). А хочется большего, где хотя бы навыки ООП смог полностью применить. Понимаю, что это навернека проблема не PHP, а фриланса

В вашем случае, это не проблема, это единственное, что вы можете делать.

В PHP тоже можно применять ООП. Причем уровень ООП зависит исключительно от программиста. Можно классы использовать просто как контейнер для статических методов, а можно и создавать «серьёзные» объекты с инкапсуляцией, наследованием, полиморфизмом. И делать это нужно не из иррационального «хочу круто с 10 уровнями абстракции», а из потребностей проекта здесь и сейчас.

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

Разбиение на методы это не ООП, это Процедурное программирование. Точнее сказать разбиение на методы в ООП это его 1%, и 80% в Процедурном. Так что ты парень описал именно второе.

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

кстати много ли проектов на пхп требуют полиформизма ?

Сложно сказать. Я например работаю с Kohana. Её классы используют полиморфизм. Мои редко. Это от задачи зависит. И от программиста.
Соответсвенно, если писать свой фреймворк/цмс — то понадобится ООП в полной мере. А если выбрать несколько полей и нарисовать табличку — то достаточно пары методов (выборка да форматирование).

ну так что вы пишете софт и вам нада использовать паттерны и полиформизм. Я счас книгу по паттернам для пхп читаю. Интересно насколько это все реально пользуется — раные там фабрики и наблюдатели.

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

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

Но, если с нуля — то наворачивать и в джаве не нужно.
гугли
Антон Кекс Как нам спасти Java

на PHP, Python, Ruby — тем более, не обязательно, если — размер и сложность проекта позволяют — НЕ использовать.

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

Вы пойдите поработайте PHP Developer в более менее серьезном проекте на Симфони 2 к примеру. Из ваших постов следует что вы РЕАЛЬНО на PHP не программировали, а были веб-мастером. По большому счету нет большой разницы между языками, это всего лишь инструмент.

А что такое «реально»? Писал различные скрипты сложности до 100 долларов. Бывало и крупнее. На фрилансе других проектов особо и не словишь, если не хочешь брать себе на голову весь проект, включая управление и фронтенд.

«реальные» проекты я на фрилансе не встречал если честно. Обычно это какое-нибудь веб-приложение: CRM, ERP, онлайн аналитика, что угодно сложнее какього-нибудь интернет-магазинчика. Когда возникают вопросы производительности, когда на проекте не Апач+Мускул+ПХП, а к примеру и монгу юзают и редис для своих целей, может пару сервайсов на ноде крутится и т.д.

Ну в таких проектах действительно интересно работать. Да, в фрилансе с этим плохо

Фрилансю я одно веб-приложение. Это ад, я Вам скажу. Да, бывало очень интересно. Но всё-таки это для коллектива, где есть разного уровня специалисты и хорошее финансирование. Одиночкой слишком выматываешься. Нужно много рутины выполнять, а поправить архитектуру, переписать пару классов — нельзя, заказчик не согласен делать паузу в добавлении мелких фич и платить за то, что «под капотом».

Потому и хочу уйти с фриланса. Мое дело должно быть программирование back-end, и только. Да и в команде веселее работается и проекты тоже более интересные.

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

Тогда вот вам разница, между PHP и Java: на Java проектов «до 100 долларов» значительно меньше. Всё.

Переход на личности это проигрыш. Может посоветуете вообще в уборщики пойти?

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

Чем генерируете сотни лулзов, чуть ли не каждым своим сообщением.

Я не писал что PHP непригоден для серьезных вещей, я просто описал преимущества Java над PHP, которые уже увидел, прочитав первые 60 страниц «Thinking in Java». А то что я мелко плаваю — и так знаю. Таков фриланс, если нет желания заниматься всем проектом, а только программированием.

Смотрите второй абзац предыдущего сообщения.

а в чем я там не прав?

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

Не понимаю где я неверно написал

Везде.
1. Для одинаковых спецов, зарплаты на пхп и Джаве одинаковы. Другое дело, что на пхп его будут называть сениором, а на Джаве — мидлом.
2. Все плюшки строгой типизации вы можете иметь в пхп
3. Без комментариев.
4. На тему «осталось» — все как раз с точностью до наоборот. Вообще, приветы из прошлого — одна из наибольших бед Джавы.
5. Программирование под веб и, скажем, мобайл — отличается весьма сильно.

Все плюшки строгой типизации вы можете иметь в пхп

Можно пример? Как в динамическом языке можно использовать плюшки строгой типизации?

а, точно. Но это на уровне функций и методов, а в телах не пойдет



/** @param integer */
function Some($param)
{
  if (!is_integer($param)) {
    throw new InvalidArgumentException('$param must be integer');
  }
  // ...
}

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

Прямая реализация ДЛЯ ФУНКЦИЙ И МЕТОДОВ есть по дефолту в пхп, вверху кинули ссылку. А вот для переменных внутри — никак, если только не городить такое везде. И вообще в любом случае это костыли динамической типизации

1. Тайпхинтинг есть только для объектов и массивов, остальные типы им не поддерживаются

2. Не никак, а прямыми явными проверками в коде или статическим анализом.

3. Даже если это костыли (а не отсутствие синтаксического сахара), то для строгой типизации, а динамическая она или статическая никакого отношения не имеет.

Более престижный — на нем пишут очень серьезные вещи, в то время пхп презирают в различных кругах
Ну мало ли кто там что презирает. Работать с пользовательским вводом (а современный веб — это приложения, и это работа именно с пользователем), с ассоциативными массивами (в которых лежат данные самых разных типов) в разы удобнее на PHP. Java в этом плане — кошмар и ужас. У PHP своя ниша, сравнивать его с Java — неразумно. Никакое ООП и строгая типизация не позволят быстро поднять сайт. Наоборот, помешают.
Более престижный — на нем пишут очень серьезные вещи, в то время пхп презирают в различных кругах
Что ты знаешь о презрении парень?) Я с 1С на C# пересел xD

Беритесь за целый проект. Или ищите сначала трудоустройство джуном на PHP на фирме, с коллективом. Это очень быстро подымает уровень, даже когда фирма не крупная и проект один.

Беритесь за целый проект

Исключено. Не чувствую себя разносторонним программистом.

Или ищите сначала трудоустройство джуном на PHP на фирме

Похоже так и сделаю

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

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

Вы нарвались прямо на хрестоматийный ответ про «всего лишь инструмент» по отношению к PHP:

«„„Окей. Представьте себе, эмм, коробку с инструментами. Набор инструментов. Выглядит нормально, инструменты как инструменты.

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

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

Берёте плоскогубцы, у которых нет зазубрин; они плоские и гладкие. Не так полезно, как могло бы быть, но ими всё ещё можно выкручивать болты.

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

Теперь представьте себе миллионы плотников, использующих такой вот набор инструментов и говорящих вам: „А что не так с этими инструментами? Я никогда не использовал ничего другого и они отлично работают!“. И плотники показывают вам, построенные ими дома с пятиугольными комнатами и крышей кверху ногами. Вы стучитесь в дверь, она просто падает внутрь и они орут на вас за то, что вы сломали их дверь.

Вот что не так с PHP.““»

Источник: habrahabr.ru/post/142140 (должен быть настольной книгой любого, кто пишет на PHP)

И таки да, сочувствую.

Ці слова можна віднести до будь якої мови програмування, яка тільки вивчається. Наприклад, я так і не зміг заставити себе програмувати на Java через подібні проблеми.

Ці слова можна віднести до будь якої мови програмування, яка тільки вивчається.

Ні, зовсім не до будь-якої. Більшість інших не мають таких проблем. PHP — аццький бардак порівняно, наприклад, з Perl, а той — з Пітоном. Ось де майже все вказане вирішено найбільш простим і логічним способом.
Одна з проблем PHP та, що було взято ті властивості Perl, котрі виходять з першого джерела його походження — спроби логічно замкнути sh до цілістної картини. Наслідком цього є нечітке ділення між значенням та строкою, що його представляє. В sh та Tcl це єдиний метод, в Perl вже не єдиний — система зламана — а в PHP взяли саме цю зламану систему, не виправивши. (В JS те ж саме, до речі.) В Пітоні ніколи не було такого сумішу.

Наприклад, я так і не зміг заставити себе програмувати на Java через подібні проблеми.

Ява в порівнянні дуже проста і логічна. Є декілька відомих проблем (наприклад, я в своїй специфіці нарвався з ходу на відсутність беззнакових цілих; але, як я розумію, це проблеми 0.1% її користувачів), але їх замало.

Це питання звички, спорити можна до нових віників. Не скажу, що мій досвід на PHP дуже великий, але нечітке ділення між значенням та рядком мені зовсім не заважало. Те ж саме і у JavaScript.

Якщо брати Java, то я звик працювати з пам’яттю. В Java ці можливості вкрай обмежені, що створює великий дискомфорт. Пишеш приблизно у такому стилі: тут на C я б зробив так. Але це Java, вона цього не дозволяє. А-а-а... можна обійти так. О, а тепер я б на С написав так. Але це Java... А в кінці риторичне питання: і чому я мучаюсь на Java?

Ну добре що на PHP можна працювати з памяттю... А якщо серйозно, то Java для того і створювалася, щоб не займатися всякими нізькорівневими речами, а займатися програмуванням

На PHP немає такої спокуси. Це скриптовий язик, і ти відразу налаштовуєшся на це. Коли ти дивишся на PHP, то єдиний алгоритм генерування шахових ходів, який приходить у мозок, це 0×88. А Java десь посеред, щоб писати обв’язки їй не вистачає динамізму. А щоб вижимати такти не вистачає низького рівня.

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

Це питання звички, спорити можна до нових віників.

Це «питання звички» доки воно не проб’є по лбу, наприклад, випадком, коли параметр зі значенням «0911» «спроститься» до 911 (реальний випадок з моєї практики) тільки тому, що воно вирішило, що в скалярі записане число. Тому і треба всі такі конверсії робити тільки явно.

Якщо брати Java, то я звик працювати з пам’яттю. В Java ці можливості вкрай обмежені,

В будь-якій «керованій» мові вони обмежені. Це плата за безпеку.

Не воно вирішило, а програміст використав змінну в арифметичному виразі. Своя логіка у цьому є. Одному подобається писати виклик функції конвертації на кожен пчих, іншого це дратує. Так само безпека в Java мене дратує, а хтось, можливо, від цього щасливий.

а програміст використав змінну в арифметичному виразі.

З яких пір a+b — аріфметичний вираз? Ще класичних прикладів:


$ jsc-3 
> []+[]

> []+{}
[object Object]
> {}+[]
0
> {}+{}
NaN

Щось не схоже це на арифметику.

Одному подобається писати виклик функції конвертації на кожен пчих, іншого це дратує.

Нема тут ніякого «кожного пчиху». Ось в Go — є — там явна конверсія треба навіть з int до int32, коли вони тотожні. А в Пітоні, наприклад, дуже слабкі правила — головне що треба — не змішувать тексти з числами...

Так само безпека в Java мене дратує, а хтось, можливо, від цього щасливий.

Вона перестане дратувати, коли почнеться пошук помилки в коді на пару мільйонів рядків.

У PHP так точно арифметичній вираз, до конкатенація рядків виконується через крапку або через подвійні лапки. Що вирішує проблему у більшості випадків.

Все одно ви так говорите, що можна подумати, що більшість часу програмісти Java/PHP полюють на баги, які пов’язані з неявним перетворенням строки на число. Можливо раз на рік, два рази на пасху це трапляється, але суттєво не впливає.

Доречі, я шукав помилки у коді, де було набагато більше двох мільйонів рядків. Що це має доводити?

Все одно ви так говорите, що можна подумати, що більшість часу програмісти Java/PHP полюють на баги, які пов’язані з неявним перетворенням строки на число. Можливо раз на рік, два рази на пасху це трапляється, але суттєво не впливає.

Більшість часу вони полюють на інші помилки, які пов’язані з тим, що мова дає занадто свободи творити бардак у простих речах.

Доречі, я шукав помилки у коді, де було набагато більше двох мільйонів рядків. Що це має доводити?

І це було на PHP? Щось не віриться. Розкажіть-но докладніше.

Більшість часу вони полюють на інші помилки, які пов’язані з тим, що мова дає занадто свободи творити бардак у простих речах.
Та й не кажи. Як тільки ці PHP-шники наплодили стільки сайтів у інтернеті, коли весь час витрачається на пошук помилок?
І це було на PHP?
Це був unsafe C/C++. Драйвер AMD Catalyst.
Як тільки ці PHP-шники наплодили стільки сайтів у інтернеті, коли весь час витрачається на пошук помилок?

Так, що помилки на цих сайтах нікого не хвилюють.

Це був unsafe C/C++. Драйвер AMD Catalyst.

О! В C/C++ такого простору для помилок вже немає, і легше тримати дісципліну.

То я порівнюю C/C++ з Java та її безпекою.

Сравнили теплое с мягким, а мир PHP продолжил создавать софт и грести бабло;)

Сравнили теплое с мягким,

Где именно?

а мир PHP продолжил создавать софт и грести бабло;)

Вы неудачники по сравнению с IBM или Курченко:) Не тем занимаетесь:)

1. C и PHP для разных задач
2. Я жив и легитимен в своем сегменте, есть чего делать и куда идти. На какие компании и персоналии мне просто плевать с высокой колокольни;)
3. Теплый ламповый ukr.nodes таки здесь. Встретите Изю — передайте, мол такой-то кланяться велел и скучает;)

C и PHP для разных задач

Теперь осталось понять, кто утверждал обратное:) Борьбой с ветряными мельницами Вы выдаёте, что не прочитали.

Теплый ламповый ukr.nodes таки здесь.

Изи мне и в FB хватает. А сюда он таки вряд ли ходок. Хотя, может, под хитрым псевдонимом...

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

Начну с того что данный пример просто история оторванная от реалий PHP.

И давно пример с fopen стал оторванным?
Какого гигабайта вообще нужно было открытие внешнего ресурса по URL вкладывать в рамки стандартного fopen?

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

По описанной аналогии Вы держите его двумя резиновыми конфетками.

А так, повторюсь, это всего лишь инструменты.

То есть статью Вы не прочитали.

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

Не, вы не подумайте, я не спорю что стандартная библиотека PHP это... непредсказуемая штука.

В статье у автора проблема что он ввиду своих привычек, думаю еще и задач, в корне неправильно воспринимает данную технологию, пытаясь проводить паралели между C, Java.
Вообще, паралели проводить не всегда стоит, а то что говорит о функциональных языках которые не ООП? Вот в Java все просто, а в %ANY_FUNCTIONAL_LANGUAGE% не так как в Java!!! Там не ООП!!!
Но это же не значит, что тот или иной подход плох.

Насчет fopen, а как бы вы говорили если бы не знали как работатают аналогичные сишные функции? Иногда, это удобно, опять же иногда, и в очень специфических случаях.

Насчет fopen, а как бы вы говорили если бы не знали как работатают аналогичные сишные функции?

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

Вариант, когда fopen() не умеет открывать по URL — устойчивый и правильный по-своему. Вариант, когда оно всегда умеет — устойчивый и правильный по-своему. Вариант, когда это управляется (например, вторым аргументом «ru» вместо «r») — тоже.
Но то, как сейчас — не годится ни в каком смысле.

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

Нет. Вы плохо прочли статью. Он говорит, что должна быть внутренняя консистентность результата. И если что-то заимствуется из C/Java/etc., то оно должно заимствоваться с полной логикой этого заимствования, или должна быть получена другая целевая, но тоже чёткая и понятная.

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

Возможно, что Вам не хватает опыта для оценки статьи потому, что никогда не пытались писать свой язык. Я пытался, хоть и крайне ограниченно (по сути, это был DSL), и я помню, как совершенно неожиданно встают вопросы этой самой логики в таких местах, о которых раньше и не мог подумать. Другие языки этот этап прошли, создав более-менее цельную логику. Лердорф с компанией даже не ставили перед собой подобные вопросы, судя по результату. Но если не ставить, возникают проблемы от того, что пользователи начинают применять средство (особенно язык) самым неожиданным и фантастическим образом, так, что автор никогда не мог себе такого представить. И вот тут и проверяется, сколько усилий было вложено в идейную базу языка. Думаю, автор компилятора бы рассказал в десятки раз больше странных примеров и тонких случаев, но таких тут что-то не видно.

Не, вы явно не понимаете сути.

Он говорит, что должна быть внутренняя консистентность результата.
(int) — это внутренний хак.
Factory pattern в Java это хак внешний над языком, с попыткой добавить функционала которого не хватает.

Так что же лучше, хак от платформы или хак внешний... Знаете хак от платформы лучше, потому что как ни крути он стандартизирован.
Каждый пример в той статье, по сути узость мышления автора.

Есть реальность. Есть задача ее можно решить за 1*n часов на Java и за 0.6*n часов на РНР. Оба инструмента дадут приемлемый результат. Стоимость часов примерно одинакова ибо нам нужно более менее нормальное решение (о да, открою секрет, программисты на РНР получают не меньше чем на Java).
Соотвественно вопрос какой инструмент использовать? Думаю ответ очевиден.

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

P.S. Я достаточно работаю программистом. Мой основной язык JS, количество его внутренних проблем огромно, но при этом всем он превосходно решает задачи.

Есть реальность. Есть задача ее можно решить за 1*n часов на Java и за 0.6*n часов на РНР. Оба инструмента дадут приемлемый результат. Стоимость часов примерно одинакова ибо нам нужно более менее нормальное решение (о да, открою секрет, программисты на РНР получают не меньше чем на Java).
Соотвественно вопрос какой инструмент использовать? Думаю ответ очевиден.

Очевидно — использовать Python, потому что стоимость будет от 0.3*n до 0.4*n. Польза, кроме скорости разработки — надёжность за счёт отсутствия неявных конверсий и диверсий, и свобода движения в случае необходимости ускорить решение — PyPy, Cython, Jython и так далее.

Или Erlang — от 0.6*n до 0.8*n, зато мы получаем кучу других полезных фишек у выходного результата, если они нужны (написание демона или иного типа долговременного сервера).

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

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

И отсюда мы можем плавно перейти к следующему пункту:

(int) — это внутренний хак.
[...]
Так что же лучше, хак от платформы или хак внешний...

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

Каждый пример в той статье, по сути узость мышления автора.

Расскажите, пожалуйста, каким образом жалоба на чрезмерно большое количество фактов, влияющих на открытие URL через fopen(), и отсутствие внятных данных, как же будет выглядеть отказ в выполнении, показывает «узость мышления» автора. Или это Вы вспомнили «ширшее надо быть, ширшее» из москворусских классиков?

Если вы берете технологию ибо она круче/лучше но не эффективней, то пожалуй вы еще не доросли до таких решений.

Это уже второй приём подтасовочной полемики в одном не сильно большом сообщении (называется Imago). Зачем Вы так?

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

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

Верю — альтернативы-то нет, другого стандартного языка для браузеров пока, увы, не ввели.

А с чего вы сделали вывод, что речь о браузерах? JS с некоторых пор прекрасно живёт на сервер-сайде.

А вообще по теме: если бы PHP был так плох как его малюют, то он бы не получил такого широкого распространения, в том числе в крупнейших проектах. По сравнению с той же Java у него есть и плюсы, а не только сплошные минусы.

JS с некоторых пор прекрасно живёт на сервер-сайде.

Где он не имеет никакого преимущества, кроме обобщения некоторого кода со страницами.

А вот для внутри браузера альтернативы нет.

А вообще по теме: если бы PHP был так плох как его малюют, то он бы не получил такого широкого распространения, в том числе в крупнейших проектах.

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

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

То есть у обоих существование не за счёт собственного качества, а за счёт уже наработанной базы.

Где он не имеет никакого преимущества, кроме обобщения некоторого кода со страницами.
Имеет. Собственно пересечение с кодовой базой фронтенда обычно минимально, но вот движок V8 вкупе с асинхронным io частенько уделывает другие интерпретируемые языки и довольно близок к компилируемым типа Java или C#, когда однопоточная асинхронность крайне желательна архитектурно. При этом простота разработки много выше чем на Java или C#, не говоря о C/C++.
То есть у обоих существование не за счёт собственного качества, а за счёт уже наработанной базы.
Не было бы обширной наработанной базы, если бы язык был плох и непригоден для серьёзных проектов. Не перерос бы он масштаба «хомяков» и «визиток», если бы дело было только во включении сервер-сайд кода прямо в html-код (тем более он был не единственным, примерно в то же время появилась, как минимум, ASP и, позже, JSP — причем не «наколенные самоделки», а поддержанные технической и маркетинговой мощью Microsoft и Sun).
но вот движок V8 вкупе с асинхронным io частенько уделывает другие интерпретируемые языки и довольно близок к компилируемым типа Java или C#, когда однопоточная асинхронность крайне желательна архитектурно.

Он же компилирует, так что неудивительно (авторы языка таки не сделали проблем возможности максимально за-JIT’ить всё).

При этом простота разработки много выше чем на Java или C#, не говоря о C/C++.

Для JS — сомнительно. Мне на нём что-то делать катастрофически сложнее, и многим вокруг тоже. В случае сервера не знаю, насколько удобно, но в случае браузера чрезмерная свобода в обращении с данными и типами в сочетании с тем, что место выполнения кода не совпадает с местом его хранения, и необходимости воспроизводить сценарий — приводит к тому, что баг поставить легко, а отладка нудная до чёрта. Регулярно даже на вполне себе вменяемых сайтах видишь какие-то нелепости типа номера платёжной карточки, представленной в формате вывода float’а с 6 значащими цифрами (rotfl), то NaN в поле температуры, то ещё какую-то хрень в этом духе.

Я получаю подобные проблемы регулярно даже в Питоне (прямо сейчас вот пытаюсь продраться, на каком этапе транспорта, включая JSON к REST-серверу и погрузку в Postgres, вместо бинарного блоба приходит пустая строка), и это в среде, обложенной тестами со сценарием, запускаемым одним пальцем, отсутствием проблем доставки кода на место и т.п. В случае же такой распределённой среды всё становится ещё хуже. Нормальный язык для браузера как раз должен был иметь максимум защит от типичных ошибок кодера.

Не перерос бы он масштаба «хомяков» и «визиток», если бы дело было только во включении сервер-сайд кода прямо в html-код (тем более он был не единственным, примерно в то же время появилась, как минимум, ASP и, позже, JSP — причем не «наколенные самоделки», а поддержанные технической и маркетинговой мощью Microsoft и Sun).

Это не так. Я в то время работал, повторюсь, в провайдере, и видел эту победную поступь своими глазами. Какие нафиг ASP и JSP в конце 90-х для мелких сайтов? Код предполагался выполняться на хостинге, где ещё 100500 таких же несчастных на одном сервере дай бог чтобы актуальной конфигурации. При этом только LAMP (на ~50% на Linux, ~50% на FreeBSD, совсем редко на какой-то менее типичной Unix-like). Админов, которые способны были бы построить Windows под ASP, не было. JSP — я помню, как я по заказу юзера настраивал Tomcat, это было ой нетривиально.
Далее, никакой эффективной виртуализации тогда не было. Даже всякие jail’ы только-только начинали появляться. Процессоры виртуализовали дико неэффективно. А ставить Windows на отдельную машину — это надо было как минимум купить collocation за >200$/месяц.
Разумеется, где-то были системы и с ASP, и с JSP, и со многими другими крутыми средствами, но таких клиентов было 1-2 на провайдера, по сравнению с тысячами простых, которые могли плавно перейти, например, от варианта «50 гривен в месяц с SSI» до «100 гривен в месяц с PHP».

Проблемы полезли позже — начиная от 2001, плотно уже с 2002 — когда началось, что этой самой PHP несколько версий, каждая следующая заметно что-то ломает, нужны общие настройки, которые могут разным юзерам требоваться по-разному, и так далее. И вот тут чрезвычайно вовремя подвернулись под руку средства типа OpenVZ: виртуализация и шейпинг ресурсов в unix-машине с эмуляцией рута, позволяющая запускать всё, что работало на общем ядре. С этого момента всех, кто хотел чуть более странного, чем дефолтный конфиг и последняя стабильная версия апача, PHP, mysql и прочего, отправлялись в сад по типу «или платите ещё в полтора раза больше и имейте полную свободу в выборе софта, или слушайте одну на всех песню про комбайн». И большинство стало чуть больше платить (рынок уже позволял), зато ставили то, что хотели, так, как хотели. При этом цены были по-прежнему ничтожные по сравнению с collocation (физической машиной), но если кому нужно было дофига ресурсов, то переход и на физическую был почти тривиальным.

Суммируя — именно возможность плавного перехода от самых простых (тупой статики) до максимально навёрнутых сайтов дала привлекательность данной технологии. Потом уже, да, несмотря на все глупости разработчиков, заработала положительная обратная связь между распространённостью, наработанностью и привлекательностью. Windows хостинг ещё много лет не давал такой свободы (возможно, не даёт и сейчас), Java — аналогично. Так что сравнивать с ними тут просто нелепо — это были средства для небожителей.

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

На той час був .ASP. Але PHP підкупав своєю простотою. Коли я вперше сів за PHP 3, то приблизно після години роботи у мене виникло враження, що я можу написати на PHP майже будь-який сайт з нуля.

На той час був .ASP.

Не на Unix.

то приблизно після години роботи у мене виникло враження, що я можу написати на PHP майже будь-який сайт з нуля.

Це враження від будь-якої Turing-повної мови:)

В мене був знайомий, що всі сайти с досить складними CGI писав на Bash, нічого іншого не визнавав.

Ти перебільшуєш вплив *nix на життя тих часів. Можна сказати, що PHP у деякій мірі сприяв переходу на *nix, тому що у якості сервера можна було використати стареньку четвірку, яка значилася у металобрухту.

У світі *nix PHP певний час конкурував з Perl, то були приблизно однакові інструменти для створення сайтів. Але почати працювати на PHP з нуля було набагато легше. Типовий програміст PHP тих часів працював у Windows, набирав код у Far + Colorer, тестував код у Windows. А далі файли заливалися по FTP на сервер, і тут я не виключаю того варіанту, що це міг бути Windows Server.

ASP також Turing повна. Більше того, про ASP були написані книжки, а не єдиний CHM-файл на 5 Mb, де була коротенька довідка по мові плюс опис функцій. Але типова ознака продуктів Microsoft, як на мене, була у тому, що відчуття простоти використання. Так, зробити можливо все, але перед цим треба була дуже багато прочитати книжок, мануалів, ...

Ти перебільшуєш вплив *nix на життя тих часів. Можна сказати, що PHP у деякій мірі сприяв переходу на *nix, тому що у якості сервера можна було використати стареньку четвірку, яка значилася у металобрухту.

Саме в цей час я був адміном інтернет-провайдера і усе бачив своїма очима. Перебільшувати нема чого з дуже простої причини: реально крім Unix нічого не було видно. Windows був в щезаюче малий кількості, провайдери не хотіли зв’язуватися з ним. Ще інше було тільки у того, хто мав натхнення та купу дурних грошей.

Типовий хостинг (>99%) того часу вже підпадав під термін LAMP, але з тим, що 50% «L» було FreeBSD, і 100% «P» було Perl; а мали варіанти не мали і цього і задовольнялись SSI. Але CGI на Perl були _окремими_ істотами, в яких ще треба було адекватно 1) закерувати запроси на них, 2) написати генерацію html і, що типовий веб-розробник завжди забував, http-заголовки. Модуль CGI це спростив, але несуттєво.

І тут серед цього з’являється крива, глючна, дивна тулза «Personal Home Page» (це вже потім його перейменували) з кривим модулем до апача (і тільки), але який дозволяє _плавно_ переходити від статичного HTML або легкого SSI до повноцінної динамічної генерації на сервері. Тільки треба включити шмат кода до сторінки. Хочеш банер? Включи генератор банера на вибір (це вже дало більше половини(!) причин включення mod_php до серверної бази), два рядки без зміни іншої частини сторінки. Хочеш список новин? Теж добавити два рядки. І так далі. А головне, що все пройшло за анекдотом «мадам, что во что должно быть встроено?» — код всеред HTML, а не навпаки, як за традиційними підходами, був прийнятний для тої ж частини IT-людства, що вважає Excel за краще.

І поки розробники різних там FastCGI оптимізували швидкість для високонавантажених серверів, PHP захопило весь нижній шар. Все прошло за Єськовським описом конкуренції в рослинному миру — не треба конкурювати на вже обороняємих теренах, треба захоплювати майже покинуті та новостворені.

К 2000 головна частина цього процесу завершилася — з появою цілих форумів на PHP. Він вже сформував власний ринок.

І саме тоді треба було замість навалювання дурних фіч зайнятися нормалізацією усеї логіки роботи цього чуда. Але...

то були приблизно однакові інструменти для створення сайтів.

Не були! Саме за причин, що я описав вище. Якщо Ви згадуєте, наприклад, mod_perl, він довго не міг вбудовуватись в сторінки (і не знаю, чи зроблено це зараз в штатних версіях).

Але почати працювати на PHP з нуля було набагато легше.

І я вказав, чому це було так.

ASP також Turing повна.

Хтось заперечував?

Але типова ознака продуктів Microsoft, як на мене, була у тому, що відчуття простоти використання. Так, зробити можливо все, але перед цим треба була дуже багато прочитати книжок, мануалів, ...

Мабуть, тут пропущене слово «не було» (перед «відчуття»).

У ті часи у мене було делька підробок на PHP, тобто це просто погляд з іншого боку. LAMP також просто ставилося під Windows й використовувалось для розробки. А якщо брати мережу підприємства або фірми, то хостінг був не потрібен.

У ті часи у мене було делька підробок на PHP, тобто це просто погляд з іншого боку.

Те, як я бачив, дає право стверджувати вже про статистику.

LAMP також просто ставилося під Windows

Може, для Вас це було просто. Для типового розробника — ні. Бачив я такі спроби... А аналога VZ-контейнерів нема ще й зараз, наскільки мені відомо.

Очевидно — использовать Python, потому что стоимость будет от 0.3*n до 0.4*n. Польза, кроме скорости разработки — надёжность за счёт отсутствия неявных конверсий и диверсий, и свобода движения в случае необходимости ускорить решение — PyPy, Cython, Jython и так далее.
Или Erlang — от 0.6*n до 0.8*n, зато мы получаем кучу других полезных фишек у выходного результата, если они нужны (написание демона или иного типа долговременного сервера).
Это был абстрактный пример, для каждой задачи свои коеффициенты. И так бывает что РНР эффективнее. Насчет дополнительных бонусов использования других технологий то я там писал следующие:
дадут приемлемый результат
Судя по вашему отвращению, складывается впечатление что вы просто питаете личную неприязнь к этому языку, не особо вижу смысла вам что-то объяснять.
Расскажите, пожалуйста, каким образом жалоба на чрезмерно большое количество фактов, влияющих на открытие URL через fopen(), и отсутствие внятных данных, как же будет выглядеть отказ в выполнении, показывает «узость мышления» автора. Или это Вы вспомнили «ширшее надо быть, ширшее» из москворусских классиков?
PHP интерпритатор, и у него есть свои настройки — это нормально.
Верю — альтернативы-то нет, другого стандартного языка для браузеров пока, увы, не ввели. После этого нет проблем рассказывать про «превосходно решает задачи», при отсутствии реального выбора.
Альтернатив на сегодня более чем нужно. Да, они почти все компилируется в JS, за некоторым исключением. Но тем не менее если вам нужна та же статическая типизация то TypeScript вам в помощь.
Это был абстрактный пример

То есть ни о чём. Ясно, спасибо.

Судя по вашему отвращению, складывается впечатление что вы просто питаете личную неприязнь к этому языку, не особо вижу смысла вам что-то объяснять.

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

PHP интерпритатор, и у него есть свои настройки — это нормально.

Так как всё-таки поведёт себя функция при попытке выполнить неразрешённое поведение? Или это зависит от ещё одной серии настроек?

И почему эти настройки настолько сложны и запутанны?

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

Которого, считаем, нет, если мы хотим реальной переносимости.

Но тем не менее если вам нужна та же статическая типизация то TypeScript вам в помощь.

К статичности типизации проблемы не сводятся.

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

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

Которого, считаем, нет, если мы хотим реальной переносимости.
К статичности типизации проблемы не сводятся.
ClojureScript, CoffeeScript, Dart and etc.etc. — там до фига чего есть.
Инструмент не может быть плохим или хорошим, он может быть не к месту или не правильно используемым.

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

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

У меня был аналогичный опыт сравнения при переходе Perl -> Python. Perl отлично держит нишу одностраничных скриптов, тут он даже опережает Python. Но когда мы выходим на уровень «10K строк кода плюс 5 библиотек», проблемы нарастают настолько, что цена продирания через них становится психологически задалбывающей. Переход вылечил практически все проблемы старого кода только за счёт читаемости и более чёткой проверки корректности действий, хотя и дал свои проблемы (отсутствие фиксации набора локальных имён переменных — шаг назад).

ClojureScript, CoffeeScript, Dart and etc.etc. — там до фига чего есть.

И они работают в Opera и IE?

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

На ногах в гору обычно лучше, чем на велосипеде или недароджнике.

смотря какая дорога) Если «полный лес» — то да

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

так я не спорю, что лучше инструмента для клепания мелких сайтов, чем пхп — нет. А дальше уже конкуренция у пхп появляется)

Можно и на ногах, и на велосипеде взобраться, но не проще на внедорожнике?
можно.
вопрос — в цене.

благодаря ужасному PHP — интернет наводнен тьмой сайтов, на бэкэнде которых — PHP

вы еще ужаса «кровавого ынтырпрайза» на джаве не видели :D

И определяется это именно тем, какие задачи он может решать и насколько эффективно он решает по сравнению с доступными альтернативами.
Так я и не предлагаю делать БД на PHP. Я говорю что этот инструмент может быть удобным, для определенного класса задач. И это не только сайты визитки, наклепать прослойку между БД, и фронтом — на нем лего и удобно, хотя для этого типа задач почти любой скриптовый язык хорошо подойдет. Опять же, вопрос в цене программистов на том или ином языке играет роль. Наличие комьюнити, нормальных фреймворков, и т.д. Факторов много, я говорю о том что PHP как инструмент, может быть и есть удобным и эффективным для решения определенных задач. Собственно не существует универсальных языков.
И они работают в Opera и IE?
Они компилятся в JS, но дебажить в старых ИЕ беда, ибо они не поддерживают соурс мапы.

Нечего на зеркало пенять, коли рожа крива

Ну, Вам виднее в этом зеркале ;)

А как обстоят дела с поиском работы для junior java developer
очень плохо обстоят. именно джава джунами — крайне тяжело найти работу.
Через сколько месяцев после перехода с PHP
зависит от общепрограммерского базиса, и степени освоения джавы.

если задумались о переходе, то можете попробовать силы освоив Zend Framework
В большинстве проектов на Java вы встретите тот же подход к архитектуре и дизайну.

Таким образом снизите риски — освоив Zend вы и в мире PHP поднимитесь на ступень выше, и в мире Java вам многое будет понятней. Zend основан на подходе «ынтырпрайзной джавы» настолько, что один метко сказал о нем — это точно не PHP way

Ниже вам писали, но повторю — не в языке дело сейчас. а в типичных подходах, фреймворках этого ЯП.

мой совет одной строкой (на основе мнения о вашем уровне по вашим постам в этой теме):
хотите с PHP в Java — освойте вначале Zend на уровне что вас возьмут по вакансии «Ищем php программиста с знанием Zend»

Хм, интересное предложение. Из фреймворков я только основы Yii изучил — скачал доки, изучил, и после пару проектов доделывал.

Yii
это, насколько понял, с Rails идеи взяты.

а Zend — с JavaEE

чистый бэкэнд на Java — это JAX-WS или REST
нечистый — JSP, JSF и т.д.

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

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

пхп презирают в различных кругах
пхп-наколеночный, или CMSный — да.
и джаву наколеночную — тоже :)

оставаясь в рамках PHP сейчас уже можете подготовиться к переходу на Java:
Реалиуйте тестовое задание (например простенький склад):
Используя серьезный PHP фреймворк, с обильным ООП; PHPUnit, Composer; Doctrine; Git/Mercurial, — напишите REST сервер, и вместо Web UI — набор функциональных тестов к его сервисам. можете написать их хоть на том же PHP, хоть набором js сценариев для node.JS

на джаве, в основном такого же типа работа, с теми же навыками проектирования и процесса разработки.

если же, не умея сделать такое задание возьметесь за джаву — то потратите больше времени на изучение, потому что — выбросите уже имеющийся опыт на php.
а задание останется тем же:
Используя Jersey/Restlet (или минимум Sping MVC); JUnit/TestNG с EasyMock/Mockito; Maven; Hibernate; Git/Mercurial, — напишите REST сервер, и вместо Web UI — набор функциональных тестов к его сервисам.

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

Как то последнее время все видится серым и скучным.
К этому программирование отношения не имеет. Например, осень наступила.
Можно себе поставить цель отрабатывать столько то часов в фрилансе на неделю, но далеко ли с таким энтузиазмом зайдешь?
Зачем?
А о чем вы думаете когда программируете?
О том как запрограммировать то или это.
Как получать удовольствие от работы (программирования)?
Было бы лучше, если бы ты конкретно описал в чем проблема, тогда может сообщество тебе чего и подсказало бы.
К этому программирование отношения не имеет. Например, осень наступила.

Все же к этому не только осень имеет отношение. Тема нелюбви к данной работе в фрилансе в качестве PHP разработчика, которому не так и часто отпадает что то дельное, развивалась очень долгое время. Обычно в фрилансе выкатывают «сделайте мне сайт», и все. Либо ты берешь себе на голову весь проект и сам после ищешь верстальщика(ибо верстать не умею и не люблю), либо ты продолжаешь писать мелкие скрипты и парсеры. А еще если учесть что в большинстве «сделайте мне сайт» это «поставьте CMS и установите модули» — то вообще желание заходить на биржу отпадает.

Зачем?
А иначе можно стать лентяем) В офисе за тебя сделали график, а в фрилансе получается либо переработка, либо недоработка.
Было бы лучше, если бы ты конкретно описал в чем проблема, тогда может сообщество тебе чего и подсказало бы.

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

А чего бы не пообщаться к коллегами из мира PHP, имеющим нехилые рейты, интерес и развитие? Кроме ивентов, один из них ведет колонку на Доу dou.ua/...s/php-digest-0
Поскольку занятие это бесплатное, возможно будет рад помочь более дельными советами;)

Ну подучи еще Яваскрипт и что там в ВЕБе.

Обязательно/ни в коем случае;)
Ценность Software Engineer большей частью состоит из умений:
— правильно готовить языки/технологии
— строить вменямые системы
— продавать системы/знания/умения
Эти скиллзы не подлежат инфляции при смене технологии, равно как и паттерны, архитектура, SDLC и пр.
Хочется чистого бэкэнда — в Java мире таки больше шансов.

Обычно в фрилансе выкатывают «сделайте мне сайт», и все.
Не такой уж и плохой вариант. Вот возможные другие:
0. Яваскрипт и т.п не предлагаю, ибо тот же вед, вид сбоку.
1. Учишь NET или Java и идешь протирать штаны в офис со всеми вытекающими последствиями. Если ты попробовал вкус свободы (фрилансерства), то от офисов тебе начнет тошнить через месяц-другой.
2. Учишь С++ и над тобой сильно издеваютс яна собеседованиях и никуда не бурут, ибо большей частью нужны люди с большим опытом и знаниями плюсов на уровне Страуструпа и опять же попадаешь в рабство (офис). Это вариант еще хуже первого.
3. Учишь С и внутренности ОС и идешь в область драйверописательсятва и т.п. Вакансий в этой части сильно меньше, чем в певом.
4. Учишь С и в ембедед. Тут вакансий еще меньше, чем в п.3
5. Идешь в науку, учишь матлаб, R и сидишь без денег — вакансий на просторах бывшего СССР нет совсем (проверено лично и на собственной шкуре). Если есть способности к наукам, есть пробивной научник, то в течении 3-5 лет пишешь дисер (лучше за границей) и делаешь ноги за границу.

Да, интересность задач обычно в порядке 5->4->3->2->0. количество денег и гемороя в обратном.

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

Или ровно наоборот. Ведь эта свобода означает и необходимость поиска заказов, ведения переговоров, заключения договоров, оформления актов и платежей.

А толку от этой свободы? Все равно ведь надо работать, да и часто по графику

еще вариант = математика + С/C++/Java == финансовая область (там правда еще что-то типа QuantLib захотят).

Это или вариант 1 — Java, NET
Вариант 5 с математикой, статистикой и финансами — это обычно за границей (лучше в Лондоне или Нью-Йорке, есть еще Гонконг) и требуется неплохое понимание финансовой кухни (всяких, опционов, фьючерсов, ванилл, интерест рейтов и т.п.)

еще раз — C/C++ и работа есть и здесь, сами недавно искали и снова будем искать, на всякие штуки типа Bonds yieald curve and surface ))) да, хорошо бы вникнуть в финансовую математику, но это дело недели-двух обычно, остальное по ходу дела.

Неделю — две вы загнули, но физики с астрономами неплохо справляются. Матмодели и алгоритмы подсчета мало чем отличаются;)

да, я в основном про физиков ) некоторые из других областей или просто подорванные в хорошем смысле тоже справляются :)там нет ничего эдакого, в отличии от физики, там все придумали люди, зачастую более ограниченные чем те, кто это осваивает :)

Во-первых, предложение вакансий по С++ с математикой и по Java, NET легко посмотреть на том же DOU. И количество первых много меньше вторых.
Во-вторых, за 2 недели финансовую математику, это как-то уж сверх оптимистично. Кванты по 4-5 лет в ВУЗах этому учатся. Ладно учтем общие курсы, но семестров 4-6 однозначно будут. И этот объем за 2 недели???

З.Ы. Я работал в подобной конторе и знаю что ты имеешь в виду под 2 неделями. Тебе квант присылает в деталях с формулами расписанную задачку, ты ее кодишь и 1-2 недели нужны для того, чтобы от финансовых терминов глаза не округлялись. 1-2 недели на запомнить пару основных терминов.

Специально глянул предложение вакансий на DOU:
matlab и R — 0
С++ - 40 (из них с требования к финансовой математике 0)
Java+NET — 200.
Как бы поддтрверждаются мои тезисы выше.

Обычно в фрилансе выкатывают «сделайте мне сайт», и все.
Не такой уж и плохой вариант. Вот возможные другие:
0. Яваскрипт и т.п не предлагаю, ибо тот же вед, вид сбоку.
1. Учишь NET или Java и идешь протирать штаны в офис со всеми вытекающими последствиями. Если ты попробовал вкус свободы (фрилансерства), то от офисов тебе начнет тошнить через месяц-другой.
2. Учишь С++ и над тобой сильно издеваютс яна собеседованиях и никуда не бурут, ибо большей частью нужны люди с большим опытом и знаниями плюсов на уровне Страуструпа и опять же попадаешь в рабство (офис). Это вариант еще хуже первого.
3. Учишь С и внутренности ОС и идешь в область драйверописательсятва и т.п. Вакансий в этой части сильно меньше, чем в певом.
4. Учишь С и в ембедед. Тут вакансий еще меньше, чем в п.3
5. Идешь в науку, учишь матлаб, R и сидишь без денег — вакансий на просторах бывшего СССР нет совсем (проверено лично и на собственной шкуре). Если есть способности к наукам, есть пробивной научник, то в течении 3-5 лет пишешь дисер (лучше за границей) и делаешь ноги за границу.

Да, интересность задач обычно в порядке 5->4->3->2->0. количество денег и гемороя в обратном.

А иначе можно стать лентяем)
От этого тебя спасет твой организм — его кормить придется.

З.Ы. не туда ответил

его кормить придется

так можно и прожить всю жизнь — чтобы поесть было и больше ничего не надо)

Обычно в фрилансе выкатывают «сделайте мне сайт», и все.
Не такой уж и плохой вариант. Вот возможные другие:
0. Яваскрипт и т.п не предлагаю, ибо тот же вед, вид сбоку.
1. Учишь NET или Java и идешь протирать штаны в офис со всеми вытекающими последствиями. Если ты попробовал вкус свободы (фрилансерства), то от офисов тебе начнет тошнить через месяц-другой.
2. Учишь С++ и над тобой сильно издеваютс яна собеседованиях и никуда не бурут, ибо большей частью нужны люди с большим опытом и знаниями плюсов на уровне Страуструпа и опять же попадаешь в рабство (офис). Это вариант еще хуже первого.
3. Учишь С и внутренности ОС и идешь в область драйверописательсятва и т.п. Вакансий в этой части сильно меньше, чем в певом.
4. Учишь С и в ембедед. Тут вакансий еще меньше, чем в п.3
5. Идешь в науку, учишь матлаб, R и сидишь без денег — вакансий на просторах бывшего СССР нет совсем (проверено лично и на собственной шкуре). Если есть способности к наукам, есть пробивной научник, то в течении 3-5 лет пишешь дисер (лучше за границей) и делаешь ноги за границу.

Да, интересность задач обычно в порядке 5->4->3->2->0. количество денег и гемороя в обратном.

А иначе можно стать лентяем)
От этого тебя спасет твой организм — его кормить придется.

Обычно в такие моменты люблю вспоминать фразу «как заставить себя что-то делать? Да никак, оставайтесь в жопе». Помогает =)

Можно еще «падающего подтолкнуть»;)

В добавление ко всему сказанному:
— походить на различные ивенты, тема особо без разницы, хоть в манчкин играть;) Главное — вживую пообщаться с себе подобными. Техника помогала не только мне.
— поизучать рынок труда, походить на собеседования. Если работу не стоит менять, то она немедленно станет самой лучшей;)
— прочитать несколько умных книжек, походить на курсы, получить сертификатов по интересующим областям причем область без разницы, хоть скрам, хоть ISTQB, BA, PM, хоть эффективное управление бизнесом.

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

Из болота два выхода — либо в нем тонуть, либо самого себя за волосы вытаскивать. Говорю как краевед;)

ну, мне в 20 к управлению и прочим подобным делам еще далеко. Да и не тянет пока что :)

«Выгорал» неоднократно. Спасение в развитии через «не могу», общении , разнообразии и достижении любых, пускай глупых целей.

Спасибо, достаточно интересный и насыщенный совет

Как то последнее время все видится серым и скучным.
Поменяйте работу. Всё.

Менять не на что. В любом случае я останусь в программировании, ибо столько плюсов нет больше нигде. А вот среду программирования и вид — навернека надо. Пожалуй фриланс мне надоел — постоянно искать заказчика, задачу, которая бы была связана с программированием, а не версткой и/или управлением всем проектом. Буду учить Java, параллельно немного фрилансить на PHP, а дальше уже заработок с помощью этого нового языка, и понемногу путь в офис.

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

python, кажется перспективным интересным востребованным

Да как то шило на мыло. Если уж менять, то на что-то другое

разве? pyton это не только инструмент для вед дизайна как php, а полноценный язык программирования (+куча библиотек), он ближе к java чем к php, разве нет?

я читал что он все равно больше веба нигде особо не используется.

он ближе к java чем к php, разве нет?

Судя по синтаксису — совершенно разные языки.

А какой смысл учить Python, когда можно учить Java? Ну т.е. смысл мне теперь бросать изучение Java и браться за Python?

я читал что он все равно больше веба нигде особо не используется.
SciPy
я читал что он все равно больше веба нигде особо не используется.

Эт’ херня какая-то, прости Митра.
Веба да, больше всего. Но дофига и научных, и управляющих задач, и вообще на верхний слой бутерброда любой логики он сейчас ложится лучше всего.

А какой смысл учить Python, когда можно учить Java? Ну т.е. смысл мне теперь бросать изучение Java и браться за Python?

Смысла бросать в любом случае нет:) А вот почитать параллельно и понять базовые вещи — очень даже есть смысл.

он ближе к java чем к php, разве нет?
конечно нет. одно из главных делений ЯП — по типу типизации — статическая-динамическая.
python весьма далек от джавы, и близок к php.

Но также и по строгости типизации: сильная и слабая. Python как раз ближе к Java, чем к PHP по этому критерию.

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

на практике, Python впрямую противопоставляется Java, потому что гораздо богаче, и как следствие — лаконичнее, без boilerplate кода. На практике, вполне часто можно услышать как люди уходят с Java именно потому что Python — совсем НЕ Java.
(как и в Ruby, уходят из Java)
тоже можно сказать и о PHP. просто в него с джавы не уходят хотя бы в силу меньших зарплат.
и потому что, как уже писали — его путь развития привел к неряшливости, к неочевидности, к нелогичности инструмента во многих местах.

если же взять за критерий наличие англоязычных операторов, то да, почти один и тот же ЯП — Python и Java

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

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

ну и субъективное мнение Java программиста — Python очень далек от Java. А вот сейчас на PHP балуюсь, о, родственничек Pythonа. «грязный», даже потому что не все в PHP что выглядит функцией — ею является. но — родственники они. а Java от них — очень далеко.

Доставляют они удовольствие пока используешь их на автомате, забывая про особые случаи. Либо делаешь хаки, упрощающие (вернее уменьшающие) код на этих случаях основанных. Но вот когда с таким кодом приходится, разбираться, то понимаешь, что явное лучше неявного :) и в этом смысле Java и Python — родственники :)

явное лучше неявного
это про Java
и в этом смысле Java и Python — родственники :)
с каких пор в Python’е появилась статическая типизация, да еще и требующая явного описания?

извините, но вы что-то не то о джаве знаете.
или о питоне.

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

Я в этом смысле как-то перестал понимать авторов дотнета. В C# статика, но все операции VM выглядят как, например, «сложить» без указания типов — а типы должны указываться тегом значения на стеке. То есть информация о типах намеренно выброшена. Далее JIT компилятор должен её вычислить заново (пусть даже явной рефлексией по типам) и применить. Как-то череззадно выходит...

ну CLR .NET — не VM. В отличие от JVM, там в машинные коды компилируется всегда, и байт код не выполняется никогда. поэтому в него и смотреть особого смысла нет.

Такой подход сейчас в Android 4.4

Далее JIT компилятор должен её вычислить заново (пусть даже явной рефлексией по типам) и применить. Как-то череззадно выходит...
и какая печаль от этого — программисту о заботах труженника — компилятора?

Haskell и Scala компиляторы — тоже ох наворочены, из-за автовывода типов. Ну и что, программисту то — какое до этого дело?
Иногда, конечно бывает дело. Ну когда перфоманс проседает, а он вот крайне важен. Но, хватает — статистического анализа разного кода, БЕЗ углубления — а почему же компилятор генерит в одном случае тормозной код, а в другом — скоростной

Причём тут статическая типизация? И в Java, и в Python типизация сильная, а не слабая.

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

на эту тему десятилетиями пишут.

о разнице между — check in compile time и check in run time

И в Java, и в Python типизация сильная, а не слабая.
при чем это деление к проверке типов во время компиляции ИЛИ во время выполнения?

из вики ru.wikipedia.org/...лабая_типизация
Python является одним из примеров языка со строгой динамической типизацией.

я вам про соленое, а вы мне про красное.

А я не знаю зачем вы мне про вкус рассказываете, когда я говорю, что Java и Python по цвету близки.

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

если практика софтостроения десятилетиями показала разницу между ЯП прежде всего по времени проверки типа — то кому какое дело до вашего или моего вкуса?

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

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

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

Когнитивная разница тоже видна:
программист на ЯП с статикой — сразу мыслит в терминах типов, их свойствах.
а программист на ЯП с динамикой — в действиях.

и т.д.

при чем тут вкусы — если на bashе мудреный скрипт ваяется за час, а на джаве, того же функционала полдня уйдет.

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

если практика софтостроения десятилетиями показала разницу между ЯП прежде всего по времени проверки типа
Что значит «прежде всего»? По каким метрикам эта разница прежде всего?
косвенно это видно по тому, как рост популярности какого-то ЯП с динамической типизацией ведет к его применению во все более крупных проектах, и опа — «почему-то» ему начинают прикручивать статическую типизацию.
Ну вот PHP — где к нему начинают прикручивать статическую типизацию?
наоборот — не припомню. в ЯП с статической типизацией динамику не вкручивают
Variant в C++?
Когнитивная разница тоже видна:
программист на ЯП с статикой — сразу мыслит в терминах типов, их свойствах.
а программист на ЯП с динамикой — в действиях.
А программист на ассемблере вообще не мыслит?
Что значит «прежде всего»?
русскому языку не учу.
Ну вот PHP — где к нему начинают прикручивать статическую типизацию?
это будет другой язык. прикручивают поэтому в ОО части
Variant в C++?
расположение данных в общей памяти существовало и в С.
да и в PL/I
это старая практика, в языках применяемых в системном программировании
А программист на ассемблере вообще не мыслит?
вы точно не мыслите. даже читать не умеете, я ведь писал о мышлении в чем-то — а вы не дочитали.

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

русскому языку не учу.
А жаль — люблю разбираться, что имеют в виду люди, пользующиеся естественными языками без осознания того, что их умолчания могут не совпадать с умолчаниями других людей, а используемые ими термины требуют уточнения, например, по одному и тому же множеству атрибутов выборка «прежде всего» может иметь разные значения в зависимости от порядка обхода множества.
это будет другой язык. прикручивают поэтому в ОО части
Где прикручивают статическую типизацию в ОО-часть PHP? Прикручивают как раз строгую, и не в ОО-часть, а в сигнатуры функций — проверка соответствия типов (некоторых, объектов и массивов, скаляры и ресурсы мимо) параметров при вызове в runtime.
расположение данных в общей памяти существовало и в С.
Тогда в PHP статическая типизация с одним типом аналогичным «вариант». Ничем же от С не отличается?
не вижу смысла далее на вас обращать внимания
Взаимно. У нас слишком разные взгляды на то, чем является статическая типизация: по-моему, она создана не для людей, а для машин, для облегчения им компиляции и статического анализа. А без общих точек диалог бессмысленен.
У нас слишком разные взгляды на то, чем является статическая типизация по-моему, она создана не для людей
ну это мнение ремесленников да, мне известно. потому что оно широко распространено, как всякое заблуждение и миф.
и которое идет вразрез с теориями формальных языков еще с 60ых.

навскидку:
Современные технологии разработки программного обеспечения располагают широким репертуаром формальных методов (formal methods), которые помогают убедиться, что система ведет себя в соответствии с некоторой спецификацией ее поведения, явной или неявной. На одном конце спектра находятся мощные конструкции, такие как логика Хоара, языки алгебраической спецификации, модальные логики и денотационные семантики. Они способны выразить самые широкие требования к корректности программ, однако часто очень трудны в использовании и требуют от программистов высочайшей квалификации. На другом конце спектра располагаются намного более скромные методы настолько скромные, что автоматические алгоритмы проверки могут быть встроены в компиляторы, компоновщики или автоматические анализаторы программ, а применять их могут даже программисты, не знакомые с теоретическими основами этих методов. Хорошо известный пример таких облегченных формальных методов (lightweight formal method) программы проверки моделей (model checkers): инструменты для поиска ошибок в таких системах с конечным числом состояний, как интегральные схемы или коммуникационные протоколы.
Другой пример, приобретающий сейчас популярность мониторинг во время исполнения (run-time monitoring): набор приемов, позволяющих системе динамически обнаруживать, что поведение одного из ее компонентов отклоняется от спецификации. Однако же самый популярный и испытанный облегченный формальный метод это системы типов (type systems), ....
Как и многие другие термины, используемые в больших сообществах, термин «система типов» трудно определить так, чтобы охватить его неформальное использование в среде разработчиков и авторов языков программирования, но чтобы при этом определение было достаточно конкретным. Вот, например, одно из возможных определений:
«Система типов это гибко управляемый синтаксический метод доказательства отсутствия в программе определенных видов поведения при помощи классификации выражений языка по разновидностям вычисляемых ими значений»

Бенджамин Пирс «Типы в языках программирования»

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

еще, из Пирса:
Систему типов можно рассматривать как статическую (static) аппроксимацию поведения программы во время выполнения. (Более того, типы термов обычно вычисляются композиционально (compositionally), то есть тип выражения зависит только от типов его подвыражений.)
Иногда слово «статический» добавляется явным образом например, говорят о «языках программирования со статической типизацией», что-бы отличить тот анализ, который производится при компиляции и который мы рассматриваем здесь, от динамической (dynamic) или латентной (latent) типизации в языках вроде Scheme, в которых теги типов (type tags) используются для различения видов объектов, находящихся в куче. Термин «динамически типизированный», по нашему мнению, неверен (его следовало бы заменить на «динамически проверяемый»), но такое употребление уже общепринято.
...
большинство систем типов могут статически проверить, что в качестве аргументов элементарных арифметических операций всегда используются числа, что объект-получатель в вызове метода всегда имеет соответствующий метод

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

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

Забавно, что почти все ваши аргументы в пользу статической типизации, являются аргументами в пользу строгой или сильной типизации. Не дать программе даже попытаться извлечь квадратный корень из строки относится к строгости типизации, а не ко времени проверки. Язык может быть статически типизирован, но проверки типов перед исполнением его конструкций могут быть очень слабые, приводящие к большому количеству трудноуловимых ошибок (например, C, где при приведении указателей их типы никак не контролируется на совместимость, а используются лишь для отсчёта смещений). А может быть язык динамический, но со строгой типизацией (тот же Python).

Ну а мою мысль, что статическая типизация создана не для людей, а для облегчения автоматического контроля корректности написанных ими программ, вы прямо подтверждаете цитатами типа «синтаксический метод доказательства отсутствия в программе определенных видов поведения». Практически очевидно, что синтаксическое доказательство является в общем случае более простым для реализации, чем анализ семантический, комбинаторный или ещё какой. Но тем не менее, с развитием и мощностей ВТ и с появлением новых алгоритмов (практически класса слабого ИИ), статический анализ успешно применяется и к динамическим слаботипизированным языкам типа того же PHP, позволяя без исполнения выявлять те же ошибки, которые ранее считалось что без исполнения могут быть выловлены лишь на статически типизированных, да ещё и строгих ЯП.

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

Да ладно. Неужели анализ на соответствие кода формально определенному синтаксису сложнее чем чтение мыслей программиста или перебор всех допустимых значений входных переменных и проверка результата на соответствие каким-то определенным (как и кем?) требованиям.

Да ладно. Неужели анализ на соответствие
«рукалицо»...
непрограммисту не объяснить.
Язык без типов высших порядков и вычислений времени компиляции реализовать проще всего.

Вам говорят про контроль, а Вы про реализацию языка, которая по своему определению тут не предполагает такого контроля.

Что-то мне кажется, что в данном случае у Вас проблемы с языком — конкретно, с восприятием данного сообщения.

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

А для кого нужно облегчение автоматического контроля корректности программ, как не для людей? ;)

Ок — для разных людей :) Статическая типизация нужна для облегчения жизни разработчикам инструментов контроля (а также трансляции и исполнения), но не разработчикам собственно прикладного ПО.

В моих краях основной источник проблем кода на Питоне — ситуации типа a.b.doX() вместо a.b.c.doX(). Ловится это тестами или тем же статическим контролем тулзами типа pylint, но последнее далеко не всегда. Со статической типизацией это было бы выловлено не позже ближайшей компиляции. С такими примерами перед глазами считать, что статическая типизация нужна только авторам всяких контрольных тулзей, я как-то не могу — язык не поворачивается.

того я и затроллил. человек несет ахинею, но уверенно так.

а любой кто работал в проекте который педалят несколько команд, сразу поймет:
«индийская» команда:
... push
ты, через пару часиков:
... pull update

и...

нет никакой разницы на каком ЯП с статической или динамической типизацией?

или — ручной мердж-резолвинг — я содрогаюсь представляя его на ЯП без явной декларации типов.

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

но — возьмем функциональные или интеграционные тесты. в зависмости от задачи они может бежать не один час.
У нас на одном проекте только на ночь запускался, ибо 9-10 часов бежал. Потом больше, пришлось дробить, ухищрятся.

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

конечно, все проблемы можно решить.
и эти — тоже, даже если это PHP.

вопрос — «стоимости» решения

нужна только авторам всяких контрольных тулзей, я как-то не могу — язык не поворачивается.
ИМХО, та чел теории не читал.
а на практике — не сталкивался.
вот и «думает» что он — думает.
а на деле — не было такого бития, вот битиЁ и не определило сознание :)

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

Проблема не в типизации как таковой, а в сложности разработки статанализаторов. Прикладному же разработчику нужен результат — уверенность, что грубых ошибок нет. Он вынужден подсказывать статанализатору что он точно не ожидает от своего кода путем указания типов в коде. Просто так «исторически сложилось», что статанализаторы (включая встроенные в компиляторы) для языков со статической типизацией работают лучше, поскольку разработчик вынужден предоставлять им избыточную и дублирующуюся информацию о типах. Современные анализаторы для того же PHP тоже могут делать подобное, и так же требуют избыточной информации о типах (аннотации PhpDoc), либо пытаются вывести её автоматически и предупреждают о (предположительно) некорректном использовании типов. Единственное существенное различие между Java и PHP с таким подходом (декларирование типа, даже если оно необязательно синтаксически) — это именно строгость/слабость типизации, статанализатору для PHP куда сложнее понять программиста когда он пытается оперировать строкой как числом: то ли он надеется на неявное приведение типов, то ли допустил ошибку, и выдаст только предупреждение, а статанализатор для Java просто не предположит первого варианта и выдаст ошибку, заставляя указать явное приведение, если это всё же не логическая ошибка, а синтаксическая.

А кто сказал, что при статистической типизации обязательна компиляция? :)

Не обязательна, это была «укладка» под основной набор шаблонных случаев. Да, статическая типизация возможна без компиляции (вспоминаем бейсики 16-битных компьютеров, с их системой, где A — вещественная, A$ — текстовая, A! — целочисленная переменная, и так далее). Но компиляция (если это настоящая компиляция, а не тупая свёртка в байткод) является сильным условием того, что проверка типов будет выполнена. И вот эту проверку принято налагать на процесс анализа исходного текста, и это правильно.

В случае упомянутого основного набора шаблонных случаев — мы имеем один характерный шаблон, под который подпадают Perl, Python, Ruby, PHP, JS и ещё десяток менее известных средств, и для которых максимум указания информации о типе (опять же в шаблонном случае) это что оно скаляр, массив, список или что-то иное; и, с другой стороны, C, C++, Java, и опять же ещё десятки имён, в которых проверяется при компиляции, в частности, что у указанного типа существует метод с указанным именем. Вы не получите такую проверку без внешнего статического анализатора в первой названной группе, и то, он будет постоянно лажаться от совершенно законных «шуточек» Python типа x.f = lambda p: ff(x,p) (после которых нельзя его отличить от метода класса, если не лезть в служебные потроха) и которые меняют сигнатуру объекта. О чём собственно и была речь.

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

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

Ну а про «избыточную и дублирующую» спишу на Ваш полемический задор. Потому что на самом деле ни хрена они не предоставляют, простого указания, что что-то есть int, совершенно недостаточно. Посмотрите на промежуточные отчёты gcc о компиляции (по -fdump-tree-all) — там есть этапы с указанием диапазона значений каждой переменной, условно вычисленного компилятором на основании кода. А в Ada можно эти диапазоны жёстко включить в описание типа. Но сколько кода на той Ada, а сколько на C/C++/etc.

Единственное существенное различие между Java и PHP с таким подходом

Мне неинтересно ограничивать рассмотрение только Java и PHP, хотя бы потому, что оба не входят в мой working set.:) А проблемы остальных я описал. Не у того вызвали не тот метод — это чуть ли не больше половины проблем при кодировании под зверей типа Python или Erlang (и тут умная IDE с анализатором «на ходу» таки способствует, по крайней мере, где она в состоянии выловить проблему).

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

Например на пхп легко забадяжить лендинг

Вот именно потому взялся учить Java. Не хочу всю жизнь заниматься написанием лендингов и установкой CMS

Не хочу всю жизнь
Вот мой пример.
Как стукнуло 40, так количество откликов на одно и тоже резюме сократилось раз 10.
Как стукнуло 45 еще в 10 раз.
Это про всю жизнь. Имей в виду, что если пойдешь по офисному пути и не в начальники, то в 45 лет опять понадобиться PHP вспоминать.
Да, у меня «математика», матлаб да плюсы.

Конкуренцию среди формошлепщиков с годами трудно выдерживать, да. А профи берут, да еще и как.
Тем более актуариев/квантов;)

Слушайте, расскажите уж, кто такой формошлепщик. Это тот кто синтез речи или идентификацию дикторов по голосу делает?

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

Огласите весь список, пожалуйста.

Чего продаем то?

Сферического С++ девелопера или С++ девелопера со специализацией в мат моделировании, ембед , гайм и т п?

У сферического шансы с годами падают, а если со специализацией-то могут и расти.

Это тот кто синтез речи или идентификацию дикторов по голосу делает?
То бишь матлаб с плюсами.

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

Год назад после 10-ого собеседования я потерял всякую надежду продать себя, как сферического .net

После детального изучения рынка и своих предпочтений была продана комбинация .net+Finance+SDLC.
Через год продался проапгрейженый .net+Investment banking+SDLC.

Тьфу-тьфу-тьфу, everyone is happy, полет нормальный и есть куда идти далее.

П.С. И да, что вы знаете о боли(тм), я писал на APL;)

То вам виднее, куда себя продать и какую комбинацию использoвать.
А я уж понаделся... на конструктивные предложения.
А некуда, на просторах бывшего Союза есть только ЦРТ, я там 6 лет проработал, а потом минских офис издох, а переезд в Питер мне никак не интересен да и от самого црт уже тошнит, от ихнего попила.
А больше ничего и нет — ЖОПАс.
А как попытался продаваться куда-то исчо, оказалось, что по причине веселых 90-х засветится в мире не смог, а здесь уже стар. Да именно так многие конторы и отвечают и украинские и минские.
Во всем бывшем Союзе, кроме нескольких известных пилящих контор (в Москве и Питере) и останков НИИ ни матлаб ни плюсы не нужны.

А переквалифицироваться в формошлепы уже никак — никому не нужен 47-летний юниор.

Вам тут финансовые мат модели предлагали — че, никак?
А скрамчик с проджект менеджментом подучить-кишка тонка? Прецедентов знаю;)

не предлагали.
начальником не люблю.

А проект-менеджмент уже скучно. Синтез, когда делал поразвлекался, все, что внедрил (часто через генерального) работало.
Все одно, чтобы нормально рулить проектом нужно быть в теме, а не клоуном со стороны, как аутсорсеры любят.

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

Давно закончилась.
И соломки хватает.
А начальником быть — призвание — не всем дано. Мне, например не дано. Могу, но не люблю.

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

Да, но что серьезное сделать можно только в большом коллективе, а я прощелкал тот момент еще в конце 90-х, когда нужно было оказываться поближе к тем местам, где подобных коллективов много (Америка). Почему прощелкал... советское восспитание, вера, что перестойка закончится и мы заживем не хуже, чем в Америке и восстановится спрос на «ученых». Я же и пионером и комсомольцем был, не успел только в партию вступить. И во многие коммунистические сказки верил.
Сейчас на весь бывший советский Союз осталось только ЦРТ. Все старые научные школы (Москва, Новосибирск, Киев, Тбилиси, Пенза, Вильнюс, Минск) в этой области умерли не без помощи названной конторы.
Недостатка специалистов в этой области ни одна речевая контора в мире сейчас не испытывает.
По сравнению с поделиями 90-х всего мира сложность разработок очень выросла.
По результатам:
Синтез английской речи сейчас уже сравним с обычным человеком, надо старательно прислушиваться, чтобы различить, основывается на HMM, русской чуть хуже, основан на unit selection подходе (но на более качественный нет спроса, да и имеющийся делался по госзаказу).
Идентификация по голосу на фразах длительностью порядка 100 секунд 0.005 ERR.
Распознавание — у гугла одно из лучших и они его не ухудшают (в этой подобласти я плохо ориентируюсь).
Фактически в областях, кроме распознавания достигнуты необходимые для общества результаты.
А вот что будет дальше с этими областями — мне сложно сказать. По всему миру внедрят системы прослушивания телефонных разговоров, синтез будут использоваться повсеместно в различных системах оповещения. В коллцентрах будут увольнять сотрудников и заменять программными комплексами. Этот процесс уже идет.
Уже сейчас любой программист может встроить в свой продукт и качественный синтез и идентификацию, если купит соответсвующую библиотеку или немного поразбирается во фришных.

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

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

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

Могу послать резюме, только куда? Вот только image именно не знаю сразу (можно было бы начать с чего простого, войти в тему, но всем надо сразу все). Знаю все, что требуются для речевых образов, правда HMM не очень. Там мат. статистику в речевых рамках, кластеризацию и т.п. Всего первичного анализа визуальных образов не знаю (в речи там спектр, кепстр, все понятно, а что в визуальных х/з).

andrey.sevastyanov (a) shopit.se
Але у другу чергу розглядається Київ

Ок, послал резюме.
Киев, так Киев, с удаленкой все непросто. потому как английский за последние 8 лет сильно утерял. Статьи там и письменный не проблема, но устный мертв.

В общем все закончилось как обычно. Именно специалист в

image recongnition
требуется и с большим опытом именно в этом.
А я не подошел, ибо специалист немного в другом: Цифровая обработка звуковых сигналов, а не визуальных.

Тогда «заткнись и умри как мужчина» © :-)

Припоминаю, как в определенные моменты моей жизни никому не были нужны радиофизика, Delphi, APL...
Но что то родственное всегда находилось, а недостающие скиллзы — прокачивал.

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

Ну в общем я че ввязался здесь в спор. По одной причине: толпы програмеров неосиливших математику в ВУЗе считают, что вот там-то золотые горы, а реальности там очень узкие области с очень ограниченным спросом на раб силу и сильно зависят от места нахождения на земном шарике.
Ну не нужна разработка танков тем, кто еще с копьями за кабанами бегает. И если такойпсих с идеями про танки в подобном племени появляется, то либо он с голоду дохнет, либо как все с копьем бегать должен. Аналогия здесь прямая. На территории бывшего Союза общества настолько же недоразвиты в сравнении с американским, на сколько аборигены пелемени мумба-юбнами с нами.

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

Но таки есть ограниченные предложения программистам-математикам, как и в аутсорсе, так и на внутреннем рынке(банки, букмекерские конторы).

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

Не заметил. Все так же на коленках фанатики лепят БПЛА или за копейки в госах. На том же DOU вакансий с matalb 0.
И кстати, в конце 90-х у вас в Виннице была контора, что какое-никакое распознавание речи делала и другие проекты, связанные с обработкой сигналов. Сейчас, я так понял ее уже нет.
Может я чего не вижу, но вы движетесь точно также, как и мы беларусы — дешевый аутсорс (в том числе и аутсорс тестирования) и уменьшение количества «серьезных» заказов.
В Минске тоже в конце 90-х и «роботов» (так иностранцы называли) по перекладке кремневых пластин делали (RECIF) и ПО для гальванических линий (ATOTECH). Сейчас ни про одних, ни про других ничуго не слышно.
Может в Украине все и по другому, по вакансиям DOU — этого не заметно.

З.Ы. А букмекерские конторы — это... нет слов.

Наукоемкого нет почти, все что есть хочет свалить на запад, как Viewdle.

П.С. «В букмекерскую контору требуется быдломатематик». — звучит неплохо.

П.П.С. Про «была держава, дрожали ляхи и тевтоны» © можно ныть очень долго.

Я больше не поныть, а услышать мнения, почему настолько сильно упал уровень местной програмерской работы с того, что был еще 10 лет назад.
Одну причину я знаю: наукоемкие проекты сложны и дороги в разработке и маржа на них меньше, еще больше маржа на работах для тестеров.
Но, количество специалистов не сильно уменьшилось, даже увеличилось, но 99% сейчас это дешевый аутсорс, а производственные западные конторы уходят и не приходят. Плохой инвестиционный климат? Но неужели в 90-х он был сильно лучше.

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

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

Из чего-то наукоемкого у нас был Маяк и Квазар-Микро. Даже в 90-е они как-то держались. Что с ними сейчас-не знаю.

Это да. Пару лет назад общался с челом, что тушками нашими торгует, вот что он мне сказал. Тушка плюсовика стоит $5000, а тушка тестера $4500, причем тушке плюсовика здесь(РБ) надо платить $2000-2500, а тушке тестера $500-1000. С точки зрения прибыли тестеры выгоднее.

Держались на старых заказах, преимущественно оборонных (там в СССР вся наука и сосредотачивалась)
Самая наукоемкость на данный момент — ТМ Impression — это проектирование, заказ комплектующих в Китае, и сборка на месте телефонов и планшетов.
Конечно-это на уровне математика в букмекерской конторе, но и то хорошо.

Есть всякая мелочь. Большие аутсорсеры в последние годы анализом данных заинетресовались. У всех есть в среднем по одному на тысячу анализаторов. На нашем проекте есть чуть-чуть NLP, Ещё где-то встречаются всякие видео еффекты (не наука, но хоть сколько нибудь технологично) оно всё есть по чуть-чуть, но по сравнению с мейстримом его мало и ищут на него «exact mach под требовани проекта».

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

Ну и возможно дейтвительно есть

«exact mach под требовани проекта»
, тут уже приводил пример общения с одним из киевских аутсорсеров. Т.е. если нашли, хорошо, не нашли, ну и фиг с ним, что-нибудь впарим.
Держались на старых заказах, преимущественно оборонных (там в СССР вся наука и сосредотачивалась)
Заказы благополучно скончались в течении 92-93 годов. Это были в массе своей не монстры-аутсорсеры, а реальные продуктовые отделы, что открывали подразделения разработчиков тут. Но где-то с начала 2000-х они массово начали уходить с рынка, а аутсорсеры начали бурно расти.

Я бы не стал ностальгировать за теми временами.
На поверку польза от большинства той «научной деятельности» оказалась с отрицательным знаком или околонулевая.
Толковых теоретиков в 2000-ные мировые университеты отсюда выгребли (да и сейчас у них хайвей для трактора хорошо налажен), а советская инженерия это менее чем на поржать по мировым меркам.
Наука тоже глобализировалась, причем очень быстро.
.
А местных достаточно сильных потребностей на науку и инженерию просто нет. По причине, например, того что нет никакого смысла вкладывать и ждать 3-5 лет оптимизации процесса на 10-20%, если депозит в банке 30% в год и любой бизнес с рентабельностью менее 50% вообще не имеет смысла.
Наука и инженерия рулят там, где толкаются на 5-10% рентабельности и огромных оборотах. И каждый выжатый процент значит миллиарды.

Ну да, а если не успел на трактор, то сам виноват :). Это не ною, это осознание сего факта.

Если не передвигаться хотя бы на скутере — трактор не светит.:-)

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

Имеете в виду R&D центры?
В Украине есть чуток, но по ним в основном восточная европа специализируется.
Разница между толковым outstaffing и R&D мала.

Сложно сказать. Вот была такая контора во Франции RECIF, открыла в Минске сборочное производство, конструирование и программирование роботов (по перекладке кремниевых пластин на фабах). Долго работали, первые серии 300-х сделали. Потом детские болезни управления положили контору. После о подразделении в Минске ничего слышно не стало — его полностью закрыли и не открывали снова.

R&D
? Наверное, это так и было. Те же конструктора одно время работали в 2 смены.

Как уже обсудили и все согласны, количество удаленных подразделений производственных контор уменьшилось, а количество аустсорса выросла. А аутсорс, понятно, в первую очередь интересует только прибыль — неважно какие тушки продавать, важно на которых маржа больше.
Более интересно понять причину ухода производственных контор.
Могу предположить, что причина затяжной мировой кризис.
Могу предположить, что совковость руководства наших стран ухудшает инвестиционный климат и не идут, но инвестиции в програмерское подразделение копеечны.
Но как-то все это натянуто. Та же средняя зарплата «итэшника» в Минске $1500 — это копейки в сравнении с европейскими.

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

Но как-то все это натянуто. Та же средняя зарплата «итэшника» в Минске $1500 — это копейки в сравнении с европейскими.
Зарплаты это в Америке, а в Европе — жизнь.
Расходы работодателя меньше, а денег на руки (учитывая в 2-3 раза выше цены) совсем мало.

И не говорите. Чувствуешь себя в таких проектах бомжем, который просит на хлеб)

Кожен отримує задоволення на свій смак. Наприклад у мене давно пропало задоволення від вивчання нових технологій. Тільки розчарування, що замість програмування треба читати мануали. Все йде по колу, але кожен раз додаються несуттєві деталі, але які потрібно пам’ятати.

Більше подобається мені розв’язування головоломок. А також написання кода, який з цим дуже близький. Наприклад, у неділю я працював над швидкою реалізацією взяття дамкою у російських шашках. Сюди можна додати читання книг, же можна узяти до себе щось нове для вирішення таких проблем. Наприклад, Д. Кнут. Також мені цікаво розбиратися у предметній галузі, наприклад, NLP (Natural Language Processing). Бо ці знання не застаріють з виходом нової бібліотеки. Також є поле для експериментів, де можна знайти щось цікаве.

Також приносить насолоду, але не в такій мірі, робота над архітектурними питаннями.

З цих міркувань я вибрав для себе startup, де все це поєднано.

NLP (Natural Language Processing)
Здесь рыбы нет (в Украине).

На жаль я цього не знав, та трохи працював у цій галузі.

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

depositphotos.com був декілька років тому, там я напрацьовував досвід. У шведському стартапі з/п була $5000 в місяць у Києві.

P. S. Просто коли ти питаєш «як», незрозуміло що відповідати.

Компания Depositphotos, основанная в 2009 году, является самым быстрорастущим фотобанком в мире.
А какое отношение к этой компании имеет NLP?

Я починав писати пошукове двигло для цієї компанії.

Как получать удовольствие от работы

Делать то что нравится.

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

Все просто — Не любите программировать, меняйте работу (ищите ту которая вам будет нравится).

пишіть щось «для себе», для людей, беріть участь в open-source проектах
opensource.com

Кто вообще сказал такую глупость, что работа должна приносить удовольствие? Смешно

Ніхто нікому нічого не винен. Але це дуже приємний бонус.

Чем работа требует больше мозговых усилий — тем важнее чтобы она нравилась. Имхо

Хочется половину своей активной жизни заниматься тем, что нравится.

Самый простой способ — это выработка условного рефлекса. Напедалил класс — съел аскорбинку.

Це не працює, можна послухати видатного бабуїнолога Роберта Сапольскі:
www.snob.ru/...ted/entry/18718
частина «відношення до нагороди».

Якщо переказати, то більше задоволення мавпа (а людина розумна це мавпа) отримує в той момент, коли перед нею ставиться завдання, ймовірність нагороди за виконання котрого дорівнює 50%. На своєму досвіді, сюди можна додати завдання, де ти не впевнений, чи зможеш його виконати (виклик).

Також цікава лекція Дана Пінка
www.snob.ru/...cted/entry/7067
Чому гроші не стимул для робітника

Не згідний. Якщо я не буду впевненим, що робота принесе винагороду — я не буду за неї братися. На рахунок нового — якщо це в області того що тобі подобається — то так. А інакше то буде викликати лише негатив, бо треба не просто зробити нецікаву тобі річ, а й додатково вивчити нецікаву область.

Мова не йде про відсутність нагороди. Просто якщо нагорода отримується у 50% випадків, то таке завдання дає більше емоції. Так що менеджер повинен поставити генератор випадкових чисел, щоб хвалити підлеглих.

Самый простой способ — это выработка условного рефлекса. Напедалил класс — съел аскорбинку.
Написал безработный =)

Я же не написал — съешьте кусочек бри или реблошона

[голосом кота Матроскина] Так у него аллерргия на аскорбинку, не больше класса в день, панимаиш.

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

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

Почти по Маслоу, но если сделать не почти, то будет как-то так:
1. Достаточная оплата
2. Хорошая и стабильная оплата, хорошие и стабильные остальные условия
3. Хорошая команда, в которую ты влился
4. Нематериальная мотивация, уважение и признание со стороны коллег, уважение и признание коллег со своей стороны
5. Саморазвитие

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

Как-то по жизни ровно наоборот получается: скучны задачи, которые изначально «противны», просты, рутинны.

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

Очень просто.
1. Поработать в не-IT.
Желательно с жестким графиком работы, штрафами за опоздания, детектором лжи на собеседовании.
2. Бонусом к первому я бы добавил офис в какой-то забитой части города, а также зарплату в гривнах.
3. Можно и мешки поносить. Хотя лучше в спортзал, конечно.
4. Прикинуть, что при нынешней ситуации в стране среднестатистические профессии, в которых можно заработать на жизнь, а не выживание — где-то около трех:
а) врач. но профессия слишком уж требует определенных врожденных навыков;
б) само собой IT;
в) работа в сфере интим-услуг. (откинем преступную составляющую — кадров, идущих туда добровольно не так уж мало).
5. Прикинуть, что для «свалить» вариант IT самый приемлимый из вышеуказанных трех.

б) и в) можно совмещать? -)))

некоторым — не просто можно, а и нужно! =)))

возможно намек на наказания за плохой код)

когда уже будут поощрения ?

так поощряют того, кто наказывает )

Ну в «в» обычно минимум два человека участвует... Так сказать, поставщик услуги и клиент :)

Странный вопрос. Удовольствие от программирования похоже на удовольствие от разгадывания кроссвордов, собирание пазлов, склеивания моделей, приготовления борща или любой подобной «алгоритмической» деятельности. Когда все делаешь правильно и результат получается хороший — то это радость от маленького достижения.
Если подобная деятельность кажется скучной и не нравится — то может быть несколько причин:
1) Приходится делать то, что уже неоднократно делал раньше. Собирать один и тот же пазл много раз подряд — скучно. Хотя некоторые всю жизнь собирают кубик Рубика, ставят рекорды и им не надоедает.
2) Приходится делать то, что умеешь плохо. В результате вместо удовольствия от хорошей работы долгие мучения и нерадостный результат. Например сварив борщ первый раз можно и не получить удовольствия. Только научившись можно порадовать себя и других.
3) Подобный род интеллектуальной деятельности вообще не нравится. Например многие не видят смысла разгадывать кроссворды или крутить головоломки «просто там». Возможно нужен другой мотиватор, кроме самого правильного решения — например приз или премия.
Лично мне всегда нравилось именно находить правильные решения. И это еще с детства — задолго до программирования. Начинается с загадок, детских головоломок, игрушек вроде пятнашек, потом математика, примеры, сложные формулы ... Постепенно формируется привычка все хорошо обдумывать и моделировать мысленно. Получается любопытно: там, где обычный человек сначала сделает -> наступит на грабли -> подумает, программист подумает -> прокрутит в голове -> и не будет делать вообще.

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

Думайте о процессе, а не о результате. Именно процесс должен доставлять удовольствие. Если нет, попробуйте технику, заставляющую концентрироваться на процессе: TDD

Кто-то получает удовольствие от процесса, кто-то — от результата или его предвкушения, а кто-то — от обеих составляющих одновременно. Каждому — своё =) К тому же, если сосредоточиться только на процессе — можно и «по голове получить». Так как заказчика/клиентов/работодателя интересует исключительно результат твоей работы.

Я отвечал на конкретный вопрос: как получать удовольствие от работы. Если я вообще что-либо в этом понимаю, то я ответил точно и самым прямым образом. Человек испытывает скуку. Скуку испытывают только тогда, когда мысли сосредоточены где-то в желаемом будущем. Вы когда-нибудь ждали, например, поезд? Ну так, без планшета и смартфона и без возможности себя занять. Это и называтся скукой. Когда вы не хотите концентрироваться на настоящем. Поэтому, надо делать интересным настоящее или хотя бы от него не отвлекаться.

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

Вы когда-нибудь ждали, например, поезд? Ну так, без планшета и смартфона и без возможности себя занять.
Ждала, и что? У меня нет планшета и смартфона, а в сумке может не оказаться ни одной книжки, но скучно не бывает. Просто в моей голове постоянно происходят какие-то процессы, и я всегда могу себя чем-нибудь занять =)
А результат откуда появляется? От желания его получить или от самой работы?
Желание результата — отличный мотиватор. Или нет?
Думаю, отвечать на этот вопрос не надо.
Надо, потому что не только о процессе, но и о результате думать надо, чтобы не возникало ситуации «движение есть, а прогресса нет».
Желание результата — отличный мотиватор. Или нет?
Нет ))
Скорее демотиватор. Ничто так не создает усталость, как желать чего-то и не иметь. Вообще, это корень всех бед и разочарований )) Это заблуждение, в которое хочется верить. Строго и однозначно, результат появляется от работы. Не зависимо СОВЕРШЕННО, что вы хотели при этом. Вы получаете результат после череды определенных действий. Чем эффективнее вы действуете, тем эффективнее результат. А если ваши мысли где-то там а не в здесь и сейчас, то очевидно, эффективность падает.

Это сейчас конечно модно думать, что надо желать, не надо ничего делать, Вселенная должна.

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

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

Я ввязался в нехороший спор о гуманитарных вещах. О психологии.

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

А знать куда вы идете не равно все время об этом думать и сгорать от желания каждую секунду. План != желание. Наметили цель и идите.

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

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

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

P.S. хотя может просто пора сходить в отпуск. Несколько лет толком не отдыхал :)

Понятное дело, вы так ТДД и не попробовали. Водопад — такой водопад. От него устают. Первое сообщение мое было об этом.

И вы ровно и подтвердили еще то, что я выше написал. Желание результата делает путь преградой. «Битва выиграна — код отдал бы другому». Код — неприятная преграда между вами и тем, что уже «выиграно».

Понятное дело, вы так ТДД и не попробовали. Водопад — такой водопад. От него устают.

От TDD устают ещё больше, если писать бессмысленные тесты :)
А если совсем серьёзно, если тема неинтересна, ничего не поможет.

Код — неприятная преграда между вами и тем, что уже «выиграно».

Ну вот о том и речь.

От TDD устают ещё больше, если писать бессмысленные тесты :)
Пишите осмысленные тесты ))
А если совсем серьёзно, если тема неинтересна, ничего не поможет.
Либо вы работаете в потоке, либо вы прокрастинируете и думаете о единорогах и унылом мирском существовании. Когда вы сосредоточены на здесь и сейчас, принципиально не может быть ничего неинтересного и ненужного. Вся неудовлетворенность возникает потому, что вы воображаете уже свой выиграш и вам неприятен путь. Жизнь состоит из моментов, здесь и сейчас. Никакого будущего не существует. Вы отравляете себе жизнь мыслями о чем-то в другом месте, забывая наслаждаться моментом.

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

Как дзен и христианство. Дзен — наслаждаюсь всем что есть прямо сейчас. Христианство: жизнь — говно, ждем рая.
Жизнь — говно — это выбор.

Жизнь состоит из моментов, здесь и сейчас.

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

А почему при этом я должен соглашаться с моментами типа «тут надо максимально напрячь мозги, чтобы понять, в каком аргументе сделана опечатка», вместо момента, например, «я попью чая и поиграю, пока мне анализатор не выдаст проблемную точку»?

Потому что у вас нет выбора. Настоящее одновариантно. Вы сейчас пьете чай? Нет? Тогда отрицать реальность, ту которая сейчас, — это гол в свои ворота. Хотите пить чай, ну пейте ))
Сама идея того, что я писал: чтобы было интересно жить, надо делать интересным здесь и сейчас, наслаждаться процессом, а не мечтать о результатах.

Причем, основное мое утверждение: именно стремление к результатам, желание результатов и делает унылым и однообразным настоящее. Оно не объективно неинтересное. Т.е. когда для вас результат становится важнее процесса.

Потому что у вас нет выбора. Настоящее одновариантно.

У меня есть выбор — я сделал себе такое настоящее, в котором мне не нужно копаться в говнокоде :)

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

Настоящий, качественный код и взрывается красиво. Ради таких моментов стоит тратить жизнь на работе:)

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

Вот пока Вы будете это противопоставлять, так и будете по уши в... например, в TDD ;(

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

Причем, основное мое утверждение: именно стремление к результатам, желание результатов и делает унылым и однообразным настоящее. Оно не объективно неинтересное. Т.е. когда для вас результат становится важнее процесса.

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

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

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

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

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

А вы попробуйте ТДД, сначала изучите а потом попробуйте честное. Сконцентируйтесь на задачах и увидите, что скучных задач не бывает.

Нравится/не нравится бывает только у бездельников, которые в не потоке. Я не говорю, что вы бездельник. Просто есть два режима — работа в потоке и прокрастинирование. Последнее создает большую усталость. Когда у вас есть время и вы его не используете, в этот момент вы переключаетесь в другой режим, в котором начинаете «капризничать». Только когда вам нечем заняться, вам приходят в голову всякие суждения, что лучше, что хуже, что приятно, что нет, что нравится, что не нравится. Не объективно работа скучная. Это ваше к ней отношение.

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

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

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

Как вы думаете, кто быстрее похудеет, тот кто этого желает или тот, кому нравится утренняя зарядка?

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

На желаниях далеко не заедешь

Но начнёшь первый шаг. А на активном движении по принципу «шаг вперёд, две назад» можно запросто уйти в неверном направлении.

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

Вы, наверно, каждую еду выкладываете в инстаграм :)

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

Рассказываете сказки )) Миллионы толстых людей с вами не согласны.

Как хотите, я уже высказал довольно точно свою т.з. А вы уже смотрите сами. Сейчас по моему мнению все время навязывается общественным мнением (или навязывают общественное мнение), что надо всего желать, что без желания ничего не бывает, что желание == целеустремленность и т.д. и т.п. Ложь.

Вы, наверно, каждую еду выкладываете в инстаграм :)

)) Даже не знаю, то такое инстраграм. Не видел еще ни разу

Сейчас по моему мнению все время навязывается общественным мнением (или навязывают общественное мнение), что надо всего желать, что без желания ничего не бывает, что желание == целеустремленность и т.д. и т.п. Ложь.

Как раз чистая правда. А проблема, видимо, в том, что Вы не провели даже такое элементарное разделение, как активная и пассивная воля. Случай «миллионов толстых людей» в том, что в лучшем случае пассивная выдаётся за активную.

Даже не знаю, то такое инстраграм. Не видел еще ни разу

Тогда бегите от него подальше — соблазн будет слишком велик.

как активная и пассивная воля

Пфф ))) Нет никакой воли. )) Воля — это то, что внушают, чтобы повысить ЧСВ. Волевой человек, это ж так круто, не лошок какой )))

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

Воля — это то, что внушают, чтобы повысить ЧСВ. Волевой человек, это ж так круто, не лошок какой )))

Ну даже не знаю, что тут сказать, если кто-то отвергает очевидное.

Хотя... попробуйте обосновать. Со ссылками на что-то приличное. Тогда продолжим.

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

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

1. Для чего нужна воля? Не преодолевать ли что-то? Преодолевать. Думаю, соглашаетесь.
2. Преодолеваете объективные преграды? Очевидно, нет. Вы преодолеваете внутренние психологические преграды.
3. Кто создатель ваших внутренних психологических преград? Вы.
4. Из этого следует, что воля нужна для решения проблем, которые вы же и создали.
5. Не создаете себе проблем, не нужна воля.

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

А активная и пассивная воля — очень похоже на классификацию после. Удобно. Одни чего-то хотели и добились, другие вроде тоже, но не добились. Значит первые активные, вторые пассивные. Только это постфактум, такая подгонка понятия под результаты.

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

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

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

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

Но ссылки — это зло. Попробуйте опровергнуть очевидное.

При необходимости, времени и настроении — запросто. Если оно действительно неверно. Но требуется разобрать «по полкам».

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

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

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

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

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

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

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

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

С таким подходом можно оправдать что угодно. Например, пожизненное сидение в горшке, извините за радикальный пример. «Всё дело в отношении», да? Вот тут вот такое рассмотрено:
www.youtube.com/...h?v=5e5wUtDhCcU

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

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

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

Ерунда. Если вами движет не ум, а психологические комплексы, то это в общем-то скверно.

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

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

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

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

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

А мной — обычное рациональное желание не погрязнуть в рутине и сделать жизнь интереснее :)

Когда это желания были рациональными )) Желание и решение, разные вещи. Я могу очень круто думать например об атомах и электронах. Совершенно не имея никаких эмоциональных привязанностей и желаний. Вот это рациональное мышление. Это наука. А желание — это эмоция. Которая мешает сосредоточиться чаще всего.

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

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

А клип вообще-то, это переворачивание с ног на голову. Вы считаете, что я такой безупречный и типа песня про меня.

Во-первых я не говорил о самообладании, а говорил только о вовлечении в процесс здесь и сейчас и не отвлечении. А человек поет, какой МОЖЕТ быть хер..вый мир. Он фантазирует о всякой возможной фигне, которая действительно может быть, и обвиняет другого человека, что тот фантазер о себе, когда как мир ТАКОЙ херовый. Нафантизировал вот так. Т.е. певец — неадекват, психует без причины, авансом. Видимо у него проблем в жизни не хватает, надо создавать в воображении ))

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

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

Это всё о ТДД, если что )) Так же и программировании оно приводит к эффективности. Точнее о YAGNI. Хотя один хрен

А клип вообще-то, это переворачивание с ног на голову.

Наоборот, на ноги.

Вы считаете, что я такой безупречный и типа песня про меня.

А? Что про Вас (хотя бы согласно с позицией в этом треде) — да, но «безупречный» — вот это вот словцо, которое тут ни к селу ни к городу, заставляет задуматься.

Он фантазирует о всякой возможной фигне, которая действительно может быть, и обвиняет другого человека, что тот фантазер о себе, когда как мир ТАКОЙ херовый.

Это что ж нужно, извините, курить, чтобы так прочесть.
В широком смысле (чтобы не вдаваться в московийскую политическую специфику) он говорит о том, что не надо занимать _активную_ позицию поиска левых оправданий тому, что должно быть очевидно зависимо от действий людей и собственной позиции лирического «героя».

Когда как сосредоточение на моменте не говорит, что вы не будете если что случится, терять самообладание.

И вот очередной домысел — про «потерю самообладания» и сразу же как нечто заведомо отрицательное. Знаете, иногда и разрушительный гнев полезен. Разумеется, когда не слишком разрушает:) Если сидящий в мутной рутине психанёт, разобъёт 100-баксовый монитор, но займётся заменой ситуации, которая принесёт выгоду на тысячи — почему бы нет? Только Вы предлагаете продолжать сидеть в... мнэээ... Zoppa Govnosite Ltd. с таким видом, будто это лучшая точка постижения прямого луча благодати Бодхихармы, творчески игнорируя подползающую к горлу мутную жижу. Что ж, даже немного завидую — вот истинный путь агни-йоги, может, Вы в последний момент испепелите эту жижу силой духа и взлетите в воздух...

Еще и еще раз доказываете, что вы не то, чтобы не принимаете мою т.з., вы просто не понимаете, о чем я говорю. Разве где-то говорил о лучах благодати и о левых оправданиях? Как раз я говорю НАОБОРОТ, о переживании момента, а не о фантазиях и оправданиях. Вы приписываете мне ровно противоположное, от чего я предлагаю отказываться.

Еще, скажу немного грубое сравнение. Вы рассуждаете как женщина. У меня была девушка, которая выносила мне мозг вопросами по поводу любой фигни: «тебе это нравится?». Вот идешь по улице, она спрашивает: «тебе нравится эта скамейка?»

Как??? Как может нравиться или не нравиться скамейка??? (самая обычная из разноцветных планок) В мире миллиарды вещей, к которым я индеферентен. Я индеферентен к носкам, к цвету зубной пасты, к сковородке, потолку, лампам, розеткам: почти к всему, что вокруг. Т.е. я не испытываю желаний или отвращений к ним. Я их просто воспринимаю. У меня так же присутсвуют и желания и отвращения, но таких объектов ГОРАЗДО меньше. Но девушки почему-то считают, что я ДОЛЖЕН иметь суждение ко всему, потому что я не смогу оперировать объектами. Получается, я должен с пристрастием думать об атомах и электронах. Иначе мне физика бы не давалась. Я должен с пристрастием любить или блевать на значок интеграла. Иначе я не смог бы думать ими.

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

Теперь ближе к теме. Вы считаете, что тот, кто может сидеть спокойно в

Zoppa Govnosite Ltd
просто фатально и несокрушимо навсегда связан с этой конторой и ему НЕ ВОЗМОЖНО ее покинуть? Просто по логике: он может покинуть или может остаться. Почему вы отказываете ему в выборе «покинуть»?

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

В общем. Еще раз по пунктам.
1. Я ничто никому здесь не навязываю. Я просто ровно ответил на вопрос ТС. А именно, у него психологическое отвращение к рутине. Я точно ответил, откуда оно берется. Надо сузить горизонт желаний. Берет он на вооружение этот совет или нет, это его дело.
2. Сужение горизонта желаний не говорит, что вместе с этим пропадает способность планировать и человек просто становится дураком. Не способен с говносайта уйти, не способен отказаться от рутины, не способен оптимизировать работу.

В общем. Еще раз по пунктам.
1. Я ничто никому здесь не навязываю. Я просто ровно ответил на вопрос ТС. А именно, у него психологическое отвращение к рутине. Я точно ответил, откуда оно берется. Надо сузить горизонт желаний.

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

Skip остальное, ибо совсем скучно.

Ну конечно скучно ))))))))

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

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

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

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

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

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

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

Зубы я сразу после сна не чищу, зачем это? ;) Их правильно чистить после каждой еды, а не со сна. Но, переделая Ваш пример — я по крайней мере способен определить, есть у меня сейчас возможность их почистить, или сейчас есть объективно более важные дела (тушить пожар, ловить кота, etc.) Вы же не даёте никакой альтернативы, кроме как между идти чистить или заниматься полноценным сеансом автопсихоанализа на тему «а нужно ли это? готов ли я? буду ли я делать выбор? хочу ли я об этом поговорить с самим собой и окружающим миром?» Зачем? Решение такого рода принимается на ходу сравнением нескольких весов в пользу типичных вариантов (валяться в кровати, любить жену, читать что-то с лаптопа, дразнить попугая, etc.) и тут нет ничего фатального, уверяю вас:) Вы же предлагаете превратить себя в Базарова только для того, чтобы регулярно чистить зубы. Как по мне, это жуткий перегиб.

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

Как??? Как может нравиться или не нравиться скамейка??? (самая обычная из разноцветных планок)

Что «выносила мозг» это уже показательно, но без большего количества подробностей я не готов это развивать. Ну а на тему скамейки — Вы что, реально не можете себе представить, по каким признакам скамейка может нравиться? У неё есть цвет (вырвиглазно розовый даст эстетическое отвращение), расположение, форма и ещё куча параметров. По каждому из них можно рассматривать много градаций «нравится» — «не нравится», формулировать это явно по полочкам или сводя воедино, прямолинейно или парадоксально, проводя аналогии на седьмом уровне ассоциаций... в общем, широчайший простор для творчества хотя бы в рамках вас как пары:)

просто фатально и несокрушимо навсегда связан с этой конторой и ему НЕ ВОЗМОЖНО ее покинуть?

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

Почему вы отказываете ему в выборе «покинуть»?

Я не отказываю! А вот Вы с Вашим прочтением категорически отказали ему в ещё одном варианте — «не покидая, сделать работу интересной». Вы действительно считаете это невозможным или просто выпустили это из рассмотрения? Если последнее, то я не прошу объяснений причин — это Вам самому нужно изучить, почему Вы отбрасываете этот вариант.

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

Знаете, такой уход всегда в каком-то смысле бегство, поражение. Даже если на этом фронте не предполагалась никакая победа, даже если самому ушедшему это неважно и он только выиграет. У него был шанс, пусть даже 0.000001%, исправить это. Но Вы принципиально считаете его нулевым... не буду повторяться, но загляните в себя, почему Вы его обнулили.

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

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

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

Это ж какой должен быть человек идиот, чтобы ему нужен был для действий всегда стимул )))
Научные задачи решали когда-нибудь? Берете и решаете. Или каждых десять секунд надо оставовить процесс мышления и вспомнить какой-то стимул? ))
Задача автоматизации рутины — это одна из умственных задач, подобно задачам физики, математики, да и создания архитектуры. Она интересна сама по себе. Разве нужен стимул для того, чтобы делать эту задачу? Если вам интересно решать задачи, интересно программировать, то и рутину автоматизировать интересно. Само занятие интересное.

Если программисту нужен стимул, или люлей дать, то скорее это не программист, ему претит работать программистом.

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

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

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

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

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

Так что нигде противоречий нет.

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

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

Это с какогот х.....я, человек, не имеющий отвращения по вашему, ограничен? Отвращение или наоборот, желание чего-то — это барьер ПО ОПРЕДЕЛЕНИЮ. Т.е. вы как элеткрон, находитесь в силовом поле. Не имея ограничений, человек свободен принимать решения головой, а не что ему жопа говорит или член или желудок или еще что-то.

И где у вас логика? Не, я в курсе, что программисты не самые умные люди. Сам программист )))

Всё что вы говорите, говорите: я ахуе..нен, потому что меня тошнит от некоторых видов деятельности.
Это ж так наркоманы рассуждают. Я ах..енен, потому что я знаю, что такое героин, а вы нет. И я от него независим, просто я знаю что такое героин, а вы нет. И то, что мне херово без него, так это потому что я знаю, что он мне нужен, а вы дебилы ограниченные, так и будете всю жизнь есть свою никчемную еду. Это не я, это вы зависимы )))

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

От чего бегство? От фантазий в реальность? Реальность же здесь и сейчас.

Логика, еще раз:
1. Отношение ваше к вещам, объектам, миру, особенно связанное с отвращениями и желаниями — субъективно. Всё что вы говорите, доказываете НАОБОРОТ, что ваше отношение к миру объективно. Вы это прямо не говорите, но всячески подразумеваете. Т.е. не вы такой а мир такой, поэтому вы к нему так относитесь.
2. Действия от наличия желаний или отвращений только в качетсве ухудшаются. Вы видимо не разу не писали код, что ли? Вы погружались в задачу когда-нибудь? Замечали, когда вы становитесь эффективным?

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

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

Это с какогот х.....я, человек, не имеющий отвращения по вашему, ограничен? Отвращение или наоборот, желание чего-то — это барьер ПО ОПРЕДЕЛЕНИЮ.

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

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

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

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

От чего бегство? От фантазий в реальность?

И по этому вопросу — тоже. Почему вдруг «от фантазий». Обоснуйте, тогда продолжим. Вариант «от обоснуя слышу», пожалуйста, не предлагать.

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

Это вы то ее менять собираетесь? Желаниями в будущем? ))) Реальность в «здесь и сейчас». И действия происходят здесь же. Сосредоточение на действиях приводит к лучшему качеству действий. Значит к лучшим результатам.

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

можно не продолжать.

Мужчинам свойственнее действовать безэмоционально.

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

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

Хорошо, беру свои слова назад, написанные Валентину. Больше не буду подозревать в нем женщину.

А про характерную черту психопатов случайно не женщина придумала? )))

А про характерную черту психопатов случайно не женщина придумала? )))

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

Ну и ладно.

Это просто мой опыт: женщины эмоциональнее, чем мужчины. Точнее, мужчины может и эмоциональны, но реже действуют исходя из эмоций. Думают рациональнее.

Это в среднем. Математические ожидания. Я не говорил, что эмоции должны отстуствовать полностью.

//Я не говорил

Вы говорили.. цитирую

Женщины не понимают, что бывает просто рациональное мышление, без никаких эмоций.

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

Это в среднем. Математические ожидания.
Дайте, пожалуйста, пруф на статистические исследования. Иначе, это не математические, а Ваши личные ожидания, обусловленные Вашим личным опытом.
Я не говорил, что эмоции должны отстуствовать полностью.
Женщины не понимают, что бывает просто рациональное мышление, без никаких эмоций.

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

Мы разнообразные ))

Дайте, пожалуйста, пруф на статистические исследования. Иначе, это не математические, а Ваши личные ожидания, обусловленные Вашим личным опытом.

Совершенно верно. Прошу прощения, что не подобрал настолько точные слова и вам показалось, что абзацы не связаны. Я исследований таких не проводил. А личный опыт богатый, хотя бы потому, что был опыт несколько лет преподавания. Через мои глаза прошло сотни парней и девушек, кто из них рациональнее, для меня очевидно. Но опыт личный.

Причем тут противоречие.
Я отвечала на одну вашу сентенція, а вы вдруг подсовываете совершенно другую, не имеющую отношения к моему ответу.

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

Нерепрезетантивен

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

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

Вы меня спросили, есть ли у меня какой-то комлекс на счет умственных способностей женщин. Я ответил, что это мой опыт.

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

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

Я буду писать то, что посчитаю нужным. Особенно, в случае всякой чуши и домыслов на мой счет.

Ну, блин. Опять )))

Ок, iDebilCounter++. Я вас услышал, счетчик увеличил. Эта переменная хранит, сколько раз меня называли дебилом. Давно в нее не заглядывал ))

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

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

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

Нелогичность. И главное: так мыслят или совсем гуманитарии или женщины: человек должен ко всему испытывать какие-либо эмоции.

Это всего лишь факт физиологии. Если он Вам кажется нелогичным — Вы родились не тем видом существа.

можно не продолжать.

Согласен.

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

Но дело как раз в том, что в отличие от животного, человек способен понимать, что будущее, хотя его еще нет, все же грозит наступить :))

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

ИМХО, баланс, гармония и еще раз баланс.

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

Тут спорить даже не о чем.

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

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

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

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

А почему тогда есть сомнения, что некоторым людям нравится программировать?

Человек способен получать удовольствие только от процесса.

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

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

Нет, ошибаюсь не я, а Вы. Марафон и спорт это просто примеры.

Даже пословица существует на этот счет «плох тот солдат, который не мечтает стать генералом» Кажется, Суворов автор.

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

Опять потеря логики. ))

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

Нужно отказываться от результатов, если нравится процесс? Думаю, нет. Может быть результат без процесса? Тоже нет. Кто добивается лучших результатов? Тот, кто лучше проходит процесс. Кто лучше проходит процесс, тот кто им увлечен или тот, кто думает: мне бы только медальку, как же тошнят меня эти тренировки?

Лучшим с своем деле программистом должна быть установка? )))
Есть такая штука, ревью кода называется. Очень увеличивает качество кода в проекте. Я годами не могу добиться и где-то увидеть, чтобы это делали нормально. А вы говорите, лучшим в своем деле.
Да я и так может быть давно лучший, кто ж видел мой код? ))) Никто ж не оценивает.

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

Так что это не у меня отсутствие логики, а у Вас отсутствие долговременной (более 40 минут) памяти.

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

Поэтому, если заменить процесс гуляния на процесс, который подразумевает не растраты, а накопления, тогда вы получаете и удовольствие и не наступает расплата за ваши удовольствия. Логично?

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

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

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

что пишете, то и читаю.

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

Балланс — это и есть противопоставление. Это когда увеличение одного параметра ведет к уменьшению другого. И вам надо найти точку баланса. А процесс и результат — не противопоставляются. Чем лучше делаете процесс, тем лучше результат. У них не обратная зависимость.

И вам всего хорошего. Видимо звезды так стали, мы не могли не поругаться )

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

Этому утверждению полно контрпримеров.
Так что доказать Вы можете только то, что ЛИЧНО ВАМ баланс не нужен.

мы не могли не поругаться )

Это Вы называете поругаться?
Сообщаю на всякий, что когда я ругаюсь, то разговариваю матом.

Балланс — это и есть противопоставление. Это когда увеличение одного параметра ведет к уменьшению другого.

Да что Вы!!!
Когда тело находится в равновесии, при увеличение действия на него одной силы, противоположная ей сила должна также увеличится, а не уменьшиться, иначе баланс будет нарушен.

А в какой системе координат? Почему силы называются противоположными? Сделайте проекцию на какую-то ось, желательно ровную ;) И получите, что чтобы выйти в сумме в ноль, при увеличении одной силы надо уменьшать другую

А мне тут говорят, что без установок на результат и стимулов я не смогу эффективно программировать.

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

нет. У меня «всё включено». Мне нравится процесс, в котором я стараюсь сделать задачу наиболее оптимальным и быстрым и качественным способом. Поэтому и YAGNI. С этого и начал. Т.е. мне как раз нравится такой процесс, где я выбираю наиболее оптимальный путь. А не просто код ради кода.

Про поток — согласен, про воображение выигрыша — не согласен.
Возможно мы говорим о разных «уровнях абстракции». Как программисту (не джуниор кодеру) — безусловно приятнее итеративный подход. Но его использование на всех уровнях проекта/бизнеса не всегда оправдано.
Я / Мы с Вами / Вы, как программист / лид / РМ локального уровня можем не знать об уровне начальства (если таковое есть) и на верхнем уровне мышление идет как раз целями. Итеративная постановка задач — может быть дополнительным средством мотивации, поддержания работоспособности команд, средством для привлечения квалифицированных сотрудников (ведь это модно! и дает возможность «планировать» свое время самостоятельно).

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

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

Жизнь — говно — это выбор.

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

ТДД, водопад или ещё что обычно в этом контексте не имеет значения. Грубо говоря, если я знаю какие тесты напишу в течении следующего месяца, и какой код будет написан для их успешного прохождения, то этот месяц будет скучным.

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

Для ТС тоже. Просто положа руку на сердце, что создает усталость? Это «глядение», сколько еще задач осталось до окончания какого-то этапа. Это как боязнь высоты. Не смотри вниз, не будешь бояться. Глянул, боишься. Так и здесь. Не смотри вперед. Работа в потоке — одна задача закончилась, взял вторую. Пока не закончил первую, не думаешь, сколько еще осталось. Хотя, план вполне может быть.
Это ТДД. В программировании.

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

Посмотрели вперед? Отказались от потока. И это уже не совсем ТДД.

Почему люди не хотят признавать обычно такой точки зрения? Потому что гораздо проще обвинить ситуацию, чем свое отношение к ситуации. Гораздо проще думать, что задачи объективно скучные. Хотя это и глупость несусветная. Скучность задач — это субъектиная вещь. Но ни разу человек не хочет быть виновен в своем настроении. Это мир плять сговорился, стал назло ему скучным.

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

Просто положа руку на сердце, что создает усталость? Это «глядение», сколько еще задач осталось до окончания какого-то этапа.

Весьма спорно. Одна текущая рутинная задача может вызывать столько усталости, сколько не вызовут и десяток новых, с вызовом впереди.

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

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

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

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

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

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

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

либо когда наступает потребность в версионности
Она (версионность) имеет смысл всегда, если проект больше пары недель. А отсюда и итерационный процесс.

Она наступает после запуска первой версии в production.
P.S. речь ведь не о системе управления версиями (git/svn/...), а именно о версионности? :)

Что или кто мешает выпускать внутренние версии каждые 2-3 недели?

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

Все еще не вижу потребности в итерациях с точки зрения проекта.
Мне кажется водопад->канбан на этом этапе более оправдан.
Либо водопад на уровне управления проектом->итерации на уровне команд разработчиков, если команды привыкли работать по итерациям.

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

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

А это уже задача того, кто управляет разработкой разделить требуемый функционал на этапы (итерации), а также обеспечить инфраструктуру проекта для этого.
Да ладно. Раскрою карты, движок синтеза русской речи разрабатывался в таком процессе и вот управлял всех этой частью и обеспечивал инфраструктуру я.
Был еще научный руководитель, с ним определялось, что и когда мы будет делать. Так как проект наукоемкий, то одни пути не подходили, приходилось переключаться на другие, экспериментировать. Но постоянно после пару месяцев работы у нас был работающий продукт с известной функциональностью.
В итоге я убедился на 100%, что если разработка продукта больше 2-4 недель, то она требует итерационного процесса.

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