выношу продолжение дискуссии к себе, чтобы иметь возможность ответить на заданные мне вопросы.
Первая ветка обсуждения, начатая здесь, пришла к такому итогу:
- thesz: Я думаю, что на Cobol нет интересной работы. Как её скоро не будет и на ООП.
- eao197: На примере недавней вашей вакансии в ПроСофте видно, что интересная с вашей точки зрения работа не способна заинтересовать толковых разработчиков материально. Более того, сам факт вашего ухода из ПроСофта демонстрирует, что инересная работа вне ООП не интересна даже вам самим.
Поэтому ваши фантазии не тему будущих перспектив ООП, полагаю, имеют мало общего с действительностью. - thesz: Как вы думаете, сколько я получаю сейчас? Как выдумаете, насколько интерена работа, которой я сейчас занимаюсь?
Вообще, создаётся впечатление, что вы принимаете возможности конкретного работодателя за неотъемлемые свойства определённого рода работ. То есть, путаете существенные и несущественные свойства.
Отвечаю следующее:
Не суть важно, сколько вы сейчас получаете и насколько вам интересна ваша нынешняя работа. Я не находил интересным ни то, чем вы занимались в ПроСофте, ни размер зарплат, который там предлагался. Я не нахожу интересным то, чем вы занимаетесь сейчас. Это означает, что отношение к работе у нас с вами совершенно разное. И тот факт, что ПроСофт не смог быстро закрыть вакансию Хаскель/C# разработчика дает мне основание полагать, что мое отношение к работе, несколько ближе к “среднему по больнице”, чем ваше. Посему и к вашим прогнозам на будущее я отношусь более чем скептически.
Вторая ветка, начатая здесь, пришла к такому итогу:
- eao197: Тот, кто поносит ООП не сможет применять ООП успешно. Тем самым, он будет работать хуже, чем тот, кто относится к ООП спокойно. Чем больше будет тех, кто работает хуже, тем более востребованны будут те, кто работает лучше.
- thesz: Это очередной логический скачок.
- eao197: Это не скачок, это наблюдение. Не доводилось видеть, чтобы люди достигали успеха используя инструменты, которые им не нравятся до такой степени, что они называют их говном.
- thesz: Вот именно. Успеха добиваются, используя полезные и приятные инструменты. Это не отменяет способности применять инструменты, который применяющий считает... удобрением.
Так что у вас налицо скачок в рассуждениях. Это не может быть закрыто "наблюдением".
Отвечаю следующее:
Мои наблюдения не отрицают возможности/способности успешно применять инструменты, которые очень сильно не нравятся. Мои наблюдения говорят лишь о том, что если это и происходит, то настолько редко, что можно не принимать этого всерьез.
Ну и еще раз, чтобы дважды не вставать, объясню свою фразу “Радует число людей, которые считают ООП говном. Чем больше вас будет, тем сложнее будет остаться без работы.” (хотя считаю, что лучше всего она объясняется байкой с bash-а). Для этого отошлю читателей к своей же заметке, ко второй ее половине, начинающейся с абзаца:
В-четвертых, раздражает непонимание того факта, что завтрашнее будущее программирования определяется вовсе не тем, что сегодня выдумывают ученые в области computer science. Т.е. то, чем обычный разработчик будет заниматься, зависит не от сегодняшнего state of the art, а от того, на чем начали писать очередную промышленную систему вчера, если не позавчера.
ООП стало тем подходом, который позволил существенно снизить сложность разработки ПО в 80-х и 90-х годах прошлого века. И свою актуальность ООП сохраняет до сих пор.
Если какие-то горячие головы сегодня отрицают ООП, обзывая его говном, или переписывают работающие куски кода “без ООП”, то это мне напоминает попытки поссать против очень сильного ветра. Пусть пытаются. Пусть и дальше отрицают. Пусть не учатся использовать ООП и пусть не пробуют делать большие системы с использованием ООП. Чем больше таких разработчиков будет, тем ценнее окажутся те, кто способен будет сопровождать и развивать то, что уже сделано вчера и то, что делается сегодня. И даже если это не кажется интересной работой, то это все равно работа, которую нужно делать. И которая оплачивается вовсе не из соображений “интересна/не интересна”.
25 комментариев:
К ООП отношусь довольно спокойно. Как и к новомодной функциональщине. Уже давно сделал очень интересное наблюдение. Чтобы пользоваться прелестями ООП недостаточно прочитать N книг по нему и пройти курс в университете на тему промышленной разработки ПО. Нужно очень много писать. Чаще и больше. Не стесняясь некоторые куски, которые писал два года назад на известный ресурс govnokod.ru (в целях профилактики здоровой самоиронии). Я лично преодолел несколько этапов (сейчас я буду их описывать, и не стесняйтесь говорить, что я ещё малолетний далб!!б - я принимаю конструктивную критику и ценю хороший юмор).
Первый - языки высокого уровня тормозят - пишу на асме. Второй - вот в этом языке есть большее число встроенных плюшек - пишу на нём. Третий - рассматриваю любую тривиальную задачу в перспективе на 15 лет - конструирую на века - в принципе из витания в абстракциях можно и не вернуться. Четвёртый (текущий) - всё тленно и всё рано или поздно будет переписываться, имеет значение НАСКОЛЬКО ты можешь на выбранном языке чётко рассказать машине что нужно делать по теме, цениться внимательность, локаничность и аскетизм. С языками первого этапа всё ясно. Второй этап - Object Pascal и С++. Третий - С++ и Ruby. Ну а четвёртый - неожиданно ловлю кайф и экономлю нервные клетки на Perl, C и Go.
Тема просто подтолкнула к излиянию. Прошу прощения за много букв.
@buffovich:
К этому нужно добавит еще и:
- объем проекта;
- время активной жизни проекта;
- количество малолетних далб!!бов, которые проходят через этот проект;
- степень безнадежности проекта;
- (не)четкость и (не)стабильность требований к проекту...
Эммм... )) Теперь я не понял ) Можно раскрыть скобки? Претензий никаких нет - просто не улавливаю релевантность.
@buffovich:
Если раскрывать скобки, то придется писать очень долго и много. Бертранд Мейер на тему ООП толмуд на тысячу страниц написал :)
Если коротко, то ООП плохо работает на маленьких задачах. Поскольку первоначальные трудозатраты на разработку ОО-модели оказываются слишком большими для проектов. Но чем больше проект, чем дольше времени он идет, тем лучше проявляет себя ООП.
Еще одна сторона медали. Динамическая vs статическая типизация. На маленьких задачах с небольшими коллективами динамические языки удобнее и быстрее в разработке, чем статические. Но стоит увеличить объем, стоит работать над проектом в течении 10-15 лет, стоит сменить большую часть проектной команды, как ситуация поменяется на обратную. И многословная дебильная Java будет много удобнее лаконичного и красивого Ruby.
Как-то так.
@eao197 то, что хаскель научен, а ооп нет -- это городская легенда, и приверженцы хаскеля ее форсят
на самом деле тайпклассы весьма похожи на интерфейсы (как в яве), а АлгТД юзаются в определенных случаях вместо классовых иерархий
там, конечно, не 100% аналогия, и афайк (причем надо проверять) ни один из подходов не является строгим подмножеством другого
да, хаскель в начале пути имел сильное влияние научного минимализма; это было бы позитивно, но сейчас хаскель (ghc haskell) оброс своими расширениями, и стал похож на с++
так что гордиться им особо не чем
Третий - рассматриваю любую тривиальную задачу в перспективе на 15 лет - конструирую на века - в принципе из витания в абстракциях можно и не вернуться. Четвёртый (текущий) - всё тленно и всё рано или поздно будет переписываться
третий этап -- это как надо было бы писать программы, будь языки программирования совершенны
и переход к четвертому этапу -- это фактически осознание несовершенства языков и нарабатывание практического навыка несовершенства обходить, углы срезать, и/или использовать для задач другие языки, несовершенства которых находятся в основном *вне* той задачи, которую ты сейчас решаешь :-)
теперь насчет govnokod.ru -- я думаю, туда ходят посмеяться, а не поанализировать код
в то же время те случаи overdesign-a что ли, когда ты был приверженцем 3-го этапа, могут быть как следствиями недостатка опыта, так и следствиями неполноценности языка
полноценный язык должен давать возможность "нарастить" дизайн в любой точке (ну почти), примерно как ооп позволяет сделать потомка любого класса (за исключением финальных)
так вот именно случаи неполноценности языка меня очень интересуют
меня интересуют не только случаи неполноценности, но и случаи неудобства, когда их высказывают опытные программисты (скажем ты, eao197, или другие)
@еао197
количество малолетних далб!!бов, которые проходят через этот проект
определенно да!
приходится рассчитывать на них, т.к. им придется читать и модернизовать этот код
вот мыщъх на рсдн вообще пишет о случае, когда из-за того, один из разрабов не понимал что такое callback, вместо коллбэков сделали итераторы
ужасно конечно, но может быть и оправдано
@имя:... (скажем ты, eao197, или другие)
Я опытный программист? O_o. Надеюсь не ирония )
@buffovich
недоговорил мысль:
полноценный язык должен давать возможность "нарастить" дизайн в любой точке (ну почти), примерно как ооп позволяет сделать потомка любого класса (за исключением финальных)
а поскольку языки неполноценны, и возможности нарастить дизайн в любой точке у них нет, приходится создавать "точки роста" дизайна заранее
вот этот вот код для создания "точки роста" на будущее как раз и является лишним, ибо *сейчас* он не нужен
кстати, языки с динамической типизацией кое в чем лучше языков со статической именно в плане того, что "точки роста" там вовсе не обязательно закладывать заранее, а можно отложить на будущее, когда потребность возникнет
если эти рассуждения кажутся слишком абстрактными, вот пример: форвардинг, т.е. "сохранить все аргументы некой функции и потом передать их другой функции в качестве аргументов"
если нам нужен форвардинг, его обычно нужно запланировать заранее
@buffovich
Я опытный программист? O_o. Надеюсь не ирония
"опытный" может пониматься в разных смыслах
речь идет о том, что ты должен не генерить шум вида "вот неудобство/недостаток языка!!1111" когда на самом деле тут имеется удобный известный способ вопрос решить
хотя конечно что понимать под удобством и общеизвестностью...
паттер "визитор", например, общеизвестен, но с моей точки зрения - неудобный костыль
@имя
govnokod.ru - хороший тренинг сбивания собственной спеси. Смех тоже бывает в профилактических целях. :-)
overdesign - хорошее слово. Запомнить надо. (не ирония)
А насчёт третьего этапа мне понравился совет, кажется, Гради Буча (или Бутча?) - не плодить ненужных сущностей. Ответ на этот вопрос можно дать, я считаю, только с помощью коллективного обсуждения. Вот дать на митинге ответ на вопрос "что это?". Можно с матами.
И я немного скептически отношусь (ну - простите меня) к таким технологиям, как UML. Если не получается объяснить что-то на живом языке или хотя бы "игрой в крокодила" на митинге - сразу должно возникнуть подозрение на улёт в метафизику. В моих pet-projects и на работе сложилась именно такая практика для объяснения, например внешних интерфейсов моей части работы и идиом использования этих интерфейсов. Желательно в идеале описывать все односложными предложениями, или просто демонстрацией использования этих интерфейсов. Если где-то есть хитрые алгоритмы, то достаточно будет сказать о их математической сложности и как проводились стресс-тесты.
Но безусловно достоинства UML я никак не принижаю и как-нибудь углублюсь в изучение этого предмета.
@buffovich
т.е. не-опытные программисты будут выдавать слишком много такого шума "вот неудобство/недостаток языка!!1111", и с ними поэтому общаться бесполезно
@buffovich:
Проблема с UML в том, что он воспринимается (а может и преподносится) как инструмент для проектирования. Хотя на деле это не более чем форма записи. И как инструмент он такой же, как ручка или бумага.
Но почему-то от UML-я ждут каких-то чудесных результатов.
@имя:
Да не в Хаскелле дело, вообще-то. Просто я пришел в ООП из простого структурного программирования. И видел, как ООП реально повышает и модульность, и разграничивает ответственность. Да и вообще позволяет бороться со сложностью путем наслоения обозримых и управляемых слоев абстракций.
Что-то я пока не видел, чтобы ФП в этом смысле ушло дальше от структурного подхода.
@имя
Насколько я знаю единственным, более-менее распространенным языком, который можно назвать "научным" является Standard ML 97, для него существует полное математическое формальное описание синтаксиса и семантики. Правда язык не чисто функциональный а гибридный.
... не плодить ненужных сущностей. Ответ на этот вопрос можно дать, я считаю, только с помощью коллективного обсуждения
мои цели несколько иные - не научиться отвечать на этот вопрос ("сущность лишняя или нет?"), а спроектировать такой язык, где потребность в лишних сущностях "на вырост" не возникала бы
дело в том, что сущность может быть лишняя сейчас, но потребоваться в будущем; и вопрос "а это нам будет нужно или нет" решается субъективно, что не есть хорошо
@Евгений
В простом структурном есть один недостаток очень слабый полиморфизм. Он как раз и мешает модульности. В ФЯ такого недостатка нет, этого уже хватает чтобы ФЯ был не хуже чем ООП.
Что-то я пока не видел, чтобы ФП в этом смысле ушло дальше от структурного подхода.
рискну предположить, что для thesz-а хаскель это не ФП, а скорее система типов (хотя, конечно, и ФП до некоторой степени тоже)
в качестве доказательства вот: http://thesz.livejournal.com/1299356.html
@имя
решается субъективно, что не есть хорошо
Ну... Тут как в чате по профильному предмету - есть слушающие, есть имеющие право голоса. Если подобрать отличную команду, то коллективное решение будет, всё-таки более или менее объективным. В любом случае нужно будет пойти на какие-то компромиссы. Если мы имеем команду из людей, которые умеют просто слушать и просто объяснять, то такой подход будет более чем объективным. Потому что в аргументах и контр-аргументах будет достаточная доля математики. И мое любимое выражение (UNIX разработчик как-никак) - KISS ("Keep It Simple, Stupid!").
@имя:
>рискну предположить, что для thesz-а хаскель это не ФП, а скорее система типов (хотя, конечно, и ФП до некоторой степени тоже)
Да в том-то и дело, что я не очень понимаю, чем же функциональщики занимаются. Страдают какой-то херней на типах.
Вот, скажем, потребовался мне объект, который дозирует исходящий трафик исходя из предшествующей нагрузки и некоторых параметров. В ООП я определяю нужный мне интерфейс. Потом реализую его, упрятывая детали реализации под капот. При этом изначально понятно, что это будет объект с состоянием, с несколькими методами-мутаторами и несколькими методами-читателями. В обычном ОО-языке все это делается легко и непринужденно.
Нахрена на всем этом навешивать клюкву из систем типов, из чистых функций, из протаскивания через них состояний объекта?
И, что самое важная, такого рода задачка -- она ведь одна из десятков, а то и сотен задачек в рамках даже не очень большого проекта. Который нужно сделать с должным качеством и в срок.
ООП с такими вещами справляется на ура. И смысла менять шило на мыло я не вижу. Пусть даже это мыло будет на системе типов :)
Нахрена на всем этом навешивать клюкву из систем типов, из чистых функций, из протаскивания через них состояний объекта?
если тебе потребуется полноценная многопоточность/параллельность/конкурентность, то возможно наиболее естественным путем будет именно такая клюква
собственно, потому и возник интерес у людей к хаскелю
однако в бОльшей части случаев оно либо не потребуется, либо будет разрулено где-то (далеко) перед этим кодом
@Rustam
языком, который можно назвать "научным" является Standard ML 97
соглашусь
и именно к нему надо было приделывать фотку эйнштейна на обложке журнала "практика ФП", а не к хаскелю
@имя:
однако в бОльшей части случаев оно либо не потребуется, либо будет разрулено где-то (далеко) перед этим кодом
Дык в том-то все и дело. С подавляющим большинством задач ООП стравляется прекрасно. Для узких ниш, конечно, нужны свои инструменты.
В любом случае нужно будет пойти на какие-то компромиссы.
лучше быть богатым и здоровым, чем...
в смысле: лучше иметь хороший язык, который не требует от людей компромиссов (точнее, требует меньше компромиссов, чем предшественник)
Если мы имеем команду из людей, которые умеют просто слушать и просто объяснять, то такой подход будет более чем объективным.
нет, он ни разу не объективен
Его Величество Случай может бросить монетку и она 4 раза упадет решкой - в результате заказчик изменит требования и случится то, что "лишняя сущность" окажется востребованной, и проект придется переписывать (а не дописывать, как это было бы в случае наличия оной "лишней сущности")
еще раз повторю - да, процедуры выработки решения группой людей интересны, но недостатки языка они лишь обходят, а не компенсируют полностью
С подавляющим большинством задач ООП стравляется прекрасно
У меня очень большие подозрения что хороший структурный + плюс какое-то средство обобщения + средство для полиморфизма будет в большинстве случаев справятся не менее прекрасно.
Таких императивных языков пока не видно, есть golang, но в нем не хватает шаблонов/генериков.
Хотя на C++ вполне можно писать в таком стиле.
Из ФЯ ML семейство (особенно OCaml) все что нужно в принципе имеют.
Отправить комментарий