при этом метод validate() генерил бы exception в случае «непрохождения» пропертями валидации данных. А мы уже из exception могли бы вытянуть какие проперти невалидны и почему.
P.S. делал я подобную муть пару лет назад — как ни крути — рано или поздно приходишь к мысли, что PHP ушербен по своей сути, и такие штуки на нем делать — wrong way.
Потому что репортеру архикачество при съемке не нужно. Но когда с репортер бегает с мыльницей — эээ… ну какой ты нафик тогда репортер? ;-) А Кэноны — хорошие зеркалки, практичные и дешевые, и если вдруг разобьют камеру — не так жалко, как Nikon.
> Можно сотни раз писать какой-то участок кода по-совему, и спустя год узнать, как это сделать проще, короче, и эффективнее.
> Многое самому узнать малореально, только в команде.
Как уже было сказано выше, перл позволяет сделать нечто многими путями. И в ряде случаев ой как непросто указать ПОЧЕМУ путь А — правильный, а путь Б — неправильный. Стало быть, сменив команду программист остается сам по себе, потому что в другой команде ээ… учились по-другому ;-) И адаптируется ли он в новой среде — еще тот вопрос, потому что фраза «это не перл-стайл» очень сильно затрагивает перловиков, считающих себя «местным гуру».
Приведу микропример из ПХП: есть print и есть echo. Дебаты ведутся уже почти 10 лет, что лучше и что правильнее использовать. И это пример всего лишь двух (двух!!!) способов, позволяющих сделать одну и ту же вещь)) А если бы их было 3 или 5? А сколько таких моментов в перле?
Отсюда вывод — проблема то в языке. Вот и получается, что на два «уверенных» программиста на перле сильно рискуют не понять друг друга. Что уж говорить про нубов))
Так и я о том же, если перл-нуб (не путать с нуб-программером) не может самостоятельно вырасти в среде перла в разумные сроки, нафик такой язык кому нужен?
> Слабый программист-одиночка может использовать Perl, и через некоторое время стать сильным программистом.
В 1997 году, имея уже тогда опыт программирования 5+ лет, я начал использовать Perl для своих веб-поделок. За неимением достойной альтернативы. Я думал, раз все пишут на Перл — значит это кому-то нужно.
Два года я потратил на борьбу с «магией» перловых модулей, пытаясь понять, как мыслили и чем руководствовались их авторы при написании кода. И вот, что я вам скажу: каждый пишет на Perl как может или хочет в меру своей распущенности и лени. После чего я оставил все попытки осилить философию этого «великого и могучего», используя его максимум для написания небольших утилит (исключительно из-за обилия модулей под что угодно в CPAN). С тех пор, лично мое мнение о Перле только одно: как язык программирования — Перл, редкостное говно, заворачивающее извилины мозга отдельно взятого программера только в его собственном, неподражаемом направлении.
> Кроме того этот слабый программист может несколько лет поработать на других ЯП, а на Perl перейти позже, когда TIMTOWTDI для него превратится из минуса в плюс.
Как Вы думаете что скажут друг другу два перл-программиста (один, скажем, дельфист в прошлом, второй — Javascripter) после того, как встретятся на дороге и сделают друг другу code review пары сотен строчек?
> Если некий инструмент не подходит для решения Ваших задач или у Вас недостаточно прямые руки для использования этого инструмента — не стоит винить инструмент.
Не надо переходить на личности. А руки… не уверен насчет абсолютной прямоты, но почему-то, этими руками мне было более чем комфортно программировать на десятке императивных языков в прошлом и на парочке ФП сегодня. Перл в эту категорию не попал. И поделом. RIP.
> Меняют язык программирования там, где нужен банальный рефакторинг. Глупость, ИМХО.
Программистов на перле маловато, вот и меняют язык на тот, где программистов уже много и будет еще больше с каждым годом. Так что не факт, что глупость. А про рефакторинг и прочие прелести, они, вероятно, знают поболее нашего. Иначе бы сейчас «рефакторинг» назывался бы несколько по-другому и вообще, проблем с кириллицей в IT-мире не было бы ;-)
То есть программист — это бессмертный безвольный раб конторы, который готов поддерживать «внутренности чёрной коробочки» бесконечно долго? Что вы будете делать, когда старый программист уволится, а новые, открыв коробочку, наотрез откажутся ее поддерживать? Для перла такая ситуация более вероятна чем для любого другого популярного языка.
1. Если речь идет о локальных переменных — однозначно my_local_variable
3. Глобалы, имена классов — MyVariable, MyFooClass
4. Константы — MY_CONSTANT
Вроде ничего не забыл?
$customer3->name('Key')
->email('key@gmail.com')
->phone('555-55-55')
->validate()
->save();
при этом метод validate() генерил бы exception в случае «непрохождения» пропертями валидации данных. А мы уже из exception могли бы вытянуть какие проперти невалидны и почему.
P.S. делал я подобную муть пару лет назад — как ни крути — рано или поздно приходишь к мысли, что PHP ушербен по своей сути, и такие штуки на нем делать — wrong way.
> Многое самому узнать малореально, только в команде.
Как уже было сказано выше, перл позволяет сделать нечто многими путями. И в ряде случаев ой как непросто указать ПОЧЕМУ путь А — правильный, а путь Б — неправильный. Стало быть, сменив команду программист остается сам по себе, потому что в другой команде ээ… учились по-другому ;-) И адаптируется ли он в новой среде — еще тот вопрос, потому что фраза «это не перл-стайл» очень сильно затрагивает перловиков, считающих себя «местным гуру».
Приведу микропример из ПХП: есть print и есть echo. Дебаты ведутся уже почти 10 лет, что лучше и что правильнее использовать. И это пример всего лишь двух (двух!!!) способов, позволяющих сделать одну и ту же вещь)) А если бы их было 3 или 5? А сколько таких моментов в перле?
Отсюда вывод — проблема то в языке. Вот и получается, что на два «уверенных» программиста на перле сильно рискуют не понять друг друга. Что уж говорить про нубов))
В 1997 году, имея уже тогда опыт программирования 5+ лет, я начал использовать Perl для своих веб-поделок. За неимением достойной альтернативы. Я думал, раз все пишут на Перл — значит это кому-то нужно.
Два года я потратил на борьбу с «магией» перловых модулей, пытаясь понять, как мыслили и чем руководствовались их авторы при написании кода. И вот, что я вам скажу: каждый пишет на Perl как может или хочет в меру своей распущенности и лени. После чего я оставил все попытки осилить философию этого «великого и могучего», используя его максимум для написания небольших утилит (исключительно из-за обилия модулей под что угодно в CPAN). С тех пор, лично мое мнение о Перле только одно: как язык программирования — Перл, редкостное говно, заворачивающее извилины мозга отдельно взятого программера только в его собственном, неподражаемом направлении.
> Кроме того этот слабый программист может несколько лет поработать на других ЯП, а на Perl перейти позже, когда TIMTOWTDI для него превратится из минуса в плюс.
Как Вы думаете что скажут друг другу два перл-программиста (один, скажем, дельфист в прошлом, второй — Javascripter) после того, как встретятся на дороге и сделают друг другу code review пары сотен строчек?
> Если некий инструмент не подходит для решения Ваших задач или у Вас недостаточно прямые руки для использования этого инструмента — не стоит винить инструмент.
Не надо переходить на личности. А руки… не уверен насчет абсолютной прямоты, но почему-то, этими руками мне было более чем комфортно программировать на десятке императивных языков в прошлом и на парочке ФП сегодня. Перл в эту категорию не попал. И поделом. RIP.
www.google.com/search?hl=ru&q=python+vacancy (185K страниц)
www.google.com/search?hl=ru&q=perl+vacancy (187K страниц)
Программистов на перле маловато, вот и меняют язык на тот, где программистов уже много и будет еще больше с каждым годом. Так что не факт, что глупость. А про рефакторинг и прочие прелести, они, вероятно, знают поболее нашего. Иначе бы сейчас «рефакторинг» назывался бы несколько по-другому и вообще, проблем с кириллицей в IT-мире не было бы ;-)