Розробка · 3 листопада 2013, 20:49 7947

Bogdan Shyiak, SE or Dev

Каким должно быть ООП?

Как-то сильно перегружено это ваше ООП.
Поверх банальной отправки сообщений и протоколов, навернуто множество концепций.
На собеседованиях стандартный вопрос: Без чего не может быть ООП? Ожидают услышать про «три кита».
Или: Назовите основные принципы ООП. Ожидаемый ответ: SOLID.
Более продвинутые спрашивают про GRASP.
Лет 5-10 назад знание UML считалось обязательным навыком без которого невозможно знать ООП.
Декламация GoF на память — так же часть ООП. При том под «знанием паттернов» подразумевают, как правило, не столько умение применять сколько рассказать главу из книги.
.
Люди сами доходят вот до таких мыслей (Контекст: dou.ua/...forums/topic/8518/#381338 ):

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

То есть наворачивают абстракции.
В реальной работе часто встречал массовое использование запрета наследованния и попытки __максимально__ скрыть члены класса (минимум публичного, максимум приватного) с применением пары паттернов для достижения цели. И это при разработке прикладного приложения, а не какой-то убер-библиотеки.
То есть ограничивая возможности использования в пользу философских концепций и прикрывая это фразами «обезопасить пользователя от ошибок в использовании компонента».
.
В общую концепцию засовывают кучи всего, что надо было бы оставить как надстройку, тем самым делая не модульную/гибкую систему, а гигантский монолитный кусок ... ну вы поняли чего.
.
Может это все следствия расцвета все тех же 23-летних синьоров? Человек много прочитал, использовать еще не научился, а хочетсо сделать все как взрослые дяди.
Может что-то другое?
.
Собственно вопрос:
Что на ваш взгляд, является необходимыми навыками/знаниями, чтобы сказать: «Я знаю ООП».
.
P.S. Буду удивлен если первый коммент будет по теме и не будет содержать вброс про ФП :)

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: ООП

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Найкращі коментарі пропустити

Alexey Kachayev 03.11.2013 23:19

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

Началось все давно — с простой идеи отказаться от оператора goto. Процесс отказа достаточно затянулся (было много адептов старого подхода), но в итоге это привнесло в программирование такую замечательную штуку как «модульность». Теперь код __нужно__ разделять на куски для переиспользования, и у нас для этого уже есть много подходов: функции / процедуры / модули / пакеты / сопрограммы / классы / тд. Разделять код оказалось просто, главное было начать.

Но затем стал другой вопрос: как разделенный код собрать в приложение? Тут появляется понятие composatibility, и подчеркну — именно composability (т.е. возможно __просто__ связать несколько участков кода в один) и есть ключевым вопросом, который в общем случае не так просто решить. Первый миф ООП, главное — разделить код на правильные куски, не верьте — главное суметь потом это собрать.

Composability функций очень высока, кроме side-effects случаев, отсюда исходит мощь и сила ФП. У классов в ООП — практически нулевая. И с «философской» точки зрения, и с чисто технической. Скрытый state внутри объекта, in-place mutability — худшее, что можно придумать с точки зрения попыток соединить два участка кода (под словом «соединить» можете читать также «протестировать», «перенести», «реиспользовать», «заменить»). Отсюда и появляются все эти паттерны, потому что объекты изначально «недружные» друг к другу нужно как-то уживать.

Вот есть у вас Еда и Собака. Может ли Еда скормиться Собаке? Или Собака может Еду съесть? Или нужен Человек, который Собаку накормит Едой? И где хранить информацию о том, что Еда может быть Съедена, а Собака Накормлена? Чем дальше в лес — тем злее дятлы. Тем толще книги о паттернах. И тем дальше вы от сути ситуации «еда −10, сытость +5».

Хотите разобраться в ООП — учите Haskell, или еще лучше ML (но на нем никто не пишет, поэтому будет скучновато). Посмотрите Camp/OCaml.

Перейти до дискусії

Ruslan Shevchenko 04.11.2013 08:23

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

Перейти до дискусії

Beaver Green 04.11.2013 15:39

ООП, ФП, UML, паттерны ... Все это только инструменты. Для того, что бы их правильно использовать — их мало выучить, их надо понимать.
Т.е. главный вопрос должен быть не «Как?», а «Зачем?».
Зачем полиморфизм? Зачем наследование? Зачем SOLID? Зачем паттерны? Зачем вообще ООП или ФП?
У специалиста есть ответ на эти вопросы. Потому что он видел разницу на практике. Студент — теоретик будет только удивляться «нахрена это все напридумывали?».
Постараюсь коротко ответить на вопрос «Зачем?»: Бороться со сложностью! Потому что:
1. Предметная область сложная сама по себе (к сайтам — визиткам это не относится).
2. Человек может удержать в уме ограниченное количество информации.
3. Люди думают по-разному и не умеют обмениваться мыслями и знаниями «напрямую».
Собственно эти ограничения и порождают всякие методики, которые позволяют «съесть слона по кусочку» — т.е. свести сложную и запутанную предметную область к иерархии вложенных абстракций, которые человек способен «прожевать».
ООП популярно потому что это простая для понимания методика, имеющая аналогии с реальными вещами. Аналогии в ООП — реальные объекты (касса, магазин, продавец), аналогия для ФП ... на ум приходит разве что эквалайзер.
Кто считает ООП излишним и «перегруженным»? Смотрим на пункты 1-3. Это девелопер, который работает:
1. Над небольшой и несложной предметной областью (или простой частью большей области).
2. Пишет свой новый код и держит его в памяти, потому что работает с ним каждый день.
3. Минимально лезет в чужой код и имеет доступ к автору для консультаций.
Т.е. фактически работает на простом и удобном проекте уровня EASY ! А что бы познать силу ООП нужно попробовать как минимум HARD. Но можно еще попробовать NIGHTMARE: попасть внутрь огромного лабиринта запутанного кода с методами — монстрами, без компаса, карты и даже понимания что это было за приложение. После этого можно стать «инквизитором», который готов карать девелоперов за каждый метод длиной больше 10 строк, каждый публичный фиелд, каждый вложенный цикл или иф, каждый класс без интерфейса и т.д.

Перейти до дискусії

Ctrl + Enter

Ctrl + Enter

Iaroslav Voitovych ¡sí, señor! 14.11.2013 01:44

Я на собеседованиях спрашиваю: «Назовите три недостатка ООП». Никто не отвечает. И это говорит о том, что НИКТО не знает что такое ООП.
ООП преподаётся в институтах как раньше история КПСС, как религия — ООП есть абсолютное благо, но вы всё равно не поймёте, потому что олухи, но мы должны попытаться вас научить.
ООП и есть религия по сути — есть набор догм, эверисинг-из-эн-обджект и в этом духе, и догмы сомнению не подвергаются.
Затем человек пытается выйти на более высокие стадии развития, пытаясь применить все эти энкапсуляции (захламляя код врапперами), и святая святых ПАТЭРНЫ, напихывая в код визитёры с делегатами, и да святится имя твоё Обджект Фэктори. Эпик фейлы подобных попыток я видел уже много раз, фейспалм джэпэгэ.
ООП по форме и содержанию является культом карго, то есть, попыткой применить набор каких-то узко-утилитарных техник для достижения Абсолютного Добра. bit.ly/1fCvp2k
Да, ОО — всего лишь полезный инструмент, если уметь им правильно пользоваться, а этого, как правило, никто не умеет.
И что, собственно, взять с людей, поторые лезут применять патерны, а что такое вычислительная сложность алгоритмов — даже не представляют...

Відповісти

Підтримати

undefined pointer 14.11.2013 10:24

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

а на кой?
Алгоритмы написаны обычно в 60ых и 70ых. максимум что бывает — их компоновка.

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

«Назовите три недостатка ООП».

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

2. ООП требует предварительного моделирования. Моделирование дело не простое, и этому не учат И редко учатьСЯ сами. этого, в общих случаях, не умеют и знатоки «вычислительной сложности алгоритмов». Хороший пример этого не умения Качество встраиваемого ПО или погром всё-таки случился. так что — «чья бы корова мычала»

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

Відповісти

Підтримати

Iaroslav Voitovych

Ще 36 коментарів

undefined pointer 14.11.2013 10:55

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

а на кой?
Алгоритмы написаны обычно в 60ых и 70ых. максимум что бывает — их компоновка.

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

«Назовите три недостатка ООП».

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

2. ООП требует предварительного моделирования. Моделирование дело не простое, и этому не учат И редко учатьСЯ сами. этого, в общих случаях, не умеют и знатоки «вычислительной сложности алгоритмов». Хороший пример этого не умения Качество встраиваемого ПО или погром всё-таки случился. так что — «чья бы корова мычала»

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

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

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

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

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

Відповісти

Підтримати

undefined pointer

Pavel Kruchina CTO 14.11.2013 11:13

Алгоритмы написаны обычно в 60ых и 70ых. максимум что бывает — их компоновка.

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 11:25

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

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

Вы часом не в ВУЗе работаете? :)

не, обычный программист.
а вы видать да, в ВУЗе преподаете «алгоритмы», если не поняли о чем речь в моем посте.

Відповісти

Підтримати

Pavel Kruchina CTO 14.11.2013 11:29

какого роста, чего — роста?

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 11:40

Проектам свойственно расти. Растет база, растет кол-во пользователей.

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

Вначале в ее разработке учавствовало пару десятков человек, — сейчас пара сотен.

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

???
Как подскочила нагрузка на MS Office с ростом количества пользователей?

Как подскочила нагрузка когда программным продуктом Х стала пользоваться еще одна компания?

Відповісти

Підтримати

Pavel Kruchina CTO 14.11.2013 11:46

Как подскочила нагрузка на MS Office с ростом количества пользователей?

Прикладными программами мир не ограничен.

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 11:58

Прикладными программами мир не ограничен.

а где я говорил что он ими ограничен?

программами бытенько перекидывающими байтики — тоже мир не ограничен.

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

основного алгоритма — это какого?
Какой основной алгоритм у программы, где внедряется такая фича?

изменит быстродействие

ыыыыыы....
Михаил Донской

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

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

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

Відповісти

Підтримати

Pavel Kruchina CTO 14.11.2013 12:05

Какой основной алгоритм у программы, где внедряется такая фича?

Ок, давайте на примерах, если с абстракциями тяжко.

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

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

Вопрос, из-за чего вы потеряли месяц работы, и как этого не допустить в дальнейшем?

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 12:21

Ок, давайте на примерах, если с абстракциями тяжко.

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

Есть у нас проверка грамматики

и?
причем тут: ООП?

Вы залезли в неё, и допилили некую фичу
...
Но QA-щики фичу завернули

а зачем я туда залез? было такое новое требование улучшить?

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

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

Часто — обращение БД неприемлимо долго — приходится тюнить саму БД, уменьшать число запросов, и много чего.

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

Вопрос, из-за чего вы потеряли месяц работы

Вопрос, а при чем тут — ООП или не ООП?

P.S.

Вопрос, из-за чего вы потеряли месяц работы

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

P.P.S.
вспомнилась старая история, у 1С версии 7.X
отчеты свыше нескольких тысяч строк начинали жутко тормозить.
Комьюинити даже дизасемблировало, и выявило крайне неэффективный обход строк, который увеличивал время прохода строк экспоненциально их количеству.
Но — такие отчеты — редкость. 1С конечно исправила потом.

И таких «багов быстродействия» тьмы в любых программах.
Откройте html файл на полгига, с гридом в 3 колонки, который сортируется по клику, джаваскриптом, ... а на смартфоне?

и «вычислительная сложность» — как поможет?

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

Відповісти

Підтримати

Pavel Kruchina CTO 14.11.2013 13:18

Вопрос, а при чем тут — ООП или не ООП?

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 13:31

Вся мои реплики о том, что умение оценить сложность алгоритма — это не пустой навык

умение слепой печати на клавиатуре — тоже.

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

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

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

Каков ваш опыт? Сколько времени вы тратите на расчет «вычислительной сложности» алгоритмов, перед тем как садитесь их реализовывать в коде на языке прогрммирования?

Відповісти

Підтримати

Pavel Kruchina CTO 14.11.2013 13:38

Каков ваш опыт? Сколько времени вы тратите на расчет «вычислительной сложности» алгоритмов, перед тем как садитесь их реализовывать в коде на языке прогрммирования?

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

Но суть не в этом. И да, я рад, что вы таки отказались от мысли «а на кой?»

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 13:49

И да, я рад, что вы таки отказались от мысли «а на кой?»

????

по моему опыту, работы в разных командах — 0,0000....

я привел ее доказательство, мысли этой — «на кой?»

то... перед каждой задачей.

ну, в NASA да, читал, что 600 строк на Си могут вылизывать несколько лет. Вполне верю
Только программист NASA — это НЕ среднестатистический программист. по виду задачи.

которая занималась оптимизацией кода,

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

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

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

P.S.

Когда я работал в команде

и сколько времени вы тратили на расчет «вычислительной сложности»?

и почему в прошедшем времени? не программируете больше, или работаете в команде где уже не тратят время на расчет «вычислительной сложности» перед написанием кода на ЯП?

Відповісти

Підтримати

Саша Ковалев 19.11.2013 01:25

потому что теперь он Технический директор — CTO по-заморски...

Відповісти

Підтримати

undefined pointer

Alex Voo 15.11.2013 09:37

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

А если нет. В смысле навок А это меньше 1% а навык Б больше, около 90% тогда как?
Пример — ТЗ и код продукта.
Умение поставить правильно ТЗ важнее чем уметь кодить,
а времени занять может очень мало ...
Как пример я иестовое задание могу сформулировать исщерпывающе за минуту, причом такое что наврядли его можно будет за час сделть ...

Відповісти

Підтримати

undefined pointer

undefined pointer 15.11.2013 09:51

чтобы правильно поставить ТЗ — нужно быть техническим менеджером, или знатоком в предметной области.
тестовое задание за минуту — это как умение написать вывод Hello world.

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

Відповісти

Підтримати

Саша Ковалев 19.11.2013 01:23

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

Відповісти

Підтримати

undefined pointer

Саша Ковалев 19.11.2013 01:28

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

Відповісти

Підтримати

Alex Voo 14.11.2013 12:34

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 12:42

а как же недостатки 4, 5 ... которые лезут, хотя бы из динамического связывания, неявного вызова

потому что эти свойства бывают преимуществами.

еще на вскидку — работа с памятью ...

и работой с памятью нередко можно смело пренебречь.
то есть тоже — не абсолютно важное «добро»

Вас волнует например сколько эта страница доу съела ОЗУ на вашем устройстве?
Меня — нет.

так как всегда найдется ряд задач

я привел списочек типов задач где ООП какашка.
вы не читали что-ли? прочтите еще раз.

Відповісти

Підтримати

Alex Voo 14.11.2013 13:42

== а как же недостатки 4, 5 ... которые лезут, хотя бы из динамического связывания, неявного вызова ==

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

А бывают и недостатками, а недостатки бывают и серезными ...

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

эти ваши слова напопинают «... а здесь поверим мы на слово ...»

Вас волнует например сколько эта страница доу съела ОЗУ на вашем устройстве?
Меня — нет.

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 13:57

— но вас должно наверн волновать, сколько раз в секунду рефрешится страница эта
но не волнует и это. утрировано, я вообще от вас узнал что она «рефрешится». и все равно — не волнует

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

— это о том что есть целые направления
конечно есть. есть тьмы устройств с 32K и меньше ОЗУ.

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

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

Відповісти

Підтримати

Alex Voo 14.11.2013 14:18

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 14:41

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

разных профессиональных навыков, инструментов, подходов, и т.д.
по факту — это так.
Отсылаю к «5 миров» Спольски.

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

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

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

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

а вы говорите что не нужно вбивать вам в голову этот факт.

находился под конторлем софта написаном на Джаве и крутящемс на Винде и написаном студентами из, даже пусть не Индии, а Украины

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

в идеале, хотелось бы чтоб и она показалась идеально ...

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

P.S.

находился под конторлем софта написаном на Джаве и

Не вникал, но и Java RTS есть, и в развитие Java ME оказывается Оракл вкладывает деньги. для эмбедед устройств. инфа с последней JavaOne.

так что боимся мы или нет — а на чем писан софт в окружающих нас устройствах — вы уверены что знаете? я нет.
как и в его надежности, уверены? даже если не Java ME или .NET Micro. Даже если это тойотовцы. и даже если там не было никакого ООП, главного врага тру программиста!
Не так давно — марсоход завис. из-за программной ошибки. повезло, удалось рестартонуть и перепрошить исправленным фирмваре.
Может критиканы ООП пусть поучат тойотовцев и насовцев софт хорошо писать?

Відповісти

Підтримати

Alex Voo 14.11.2013 15:16

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

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

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

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 15:40

Критикуют, конструкивно, ООП те, кто понимает

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

чем вещей написаних с использованием ООП там где оно излишне.

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

тоесть не существует лучших аналогов / подобий чем сделали вы?

страничку доу делал не я.

неужели там нет ничего лишнего ...

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

кто хочет работать без выходных?

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

Только если софт для склада будет работать также надежно как и софт для легких, то мир станет лучше,

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

а если наоборот то ...

то мир остается таким какой есть — действительным, реальным. миру до идеалистов дела нет :)

а теперь чесно как часто вашу базу данных приходится править?

зависит от мира. закон изменился — наверное придется править. изменились свойства предметной области, наверное придется править

наверное и специальная прожка есть ... идет в комплекте к системе ...

и? прожка, или часть функционала — к чему вопрос?

И чем это лучше складской тетради?

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

и чем отличается от калькулятора?

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

Відповісти

Підтримати

Alex Voo 14.11.2013 16:15

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

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

опять пришли к «тяп, ляп и побыстрей в продакщен» :)

это уже доказано, что рестарт складского сервера ухудшает мир?

заберетие вопросительный знак и получте ответ.
Если не согласитесь попробуйте рестартовать каждые 30 сек после старта :)

Когда больше нечем заняться — конечно можно и лишнее убрать.

а зачем его была добавлять изначально?

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

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 16:33

опять пришли к «тяп, ляп и побыстрей в продакщен» :)

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

Если не согласитесь попробуйте рестартовать каждые 30 сек после старта

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

вам не нравится такое ПО? ну так не пользуйтесь.
Можете написать лучше? — ну так напишите.
сделайте мир лучше, раз поучаете как его сделать лучше!
;)

а зачем его была добавлять изначально?

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

а чтож ваши обекти так плохи и так плохо моделируют реальний мир?

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

вот я знаю контролеры котрие отработали по 30 лет и более ...

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

а кагда ваша система ищет ответ на подобний вопрос

когда ее спрашвают.
или когда нужно реализовать изменение информации с учетом правила — «наличие доступного остатка»

какие еще действия вы предусматрели ...

какие пользователь просил.

или если поставить обородоване в 5 раз дороже ваша система в 4,5 раза быстрее даст ответ?

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

вообще, не понял вопроса.

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

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

Вы можете дать ответ?

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

Відповісти

Підтримати

Alex Voo 14.11.2013 17:11

ну раз про НАСА написали вы и про марсоход,
то есть вещи подревнее, когда и про ООП еще не знали
ru.wikipedia.org/wiki/Пионер-10
ru.wikipedia.org/wiki/Вояджер-1
ru.wikipedia.org/wiki/Вояджер-2
там тоже были неудачи
ru.wikipedia.org/wiki/Пионер-11
так что по =живучести= продукта — марсаход поделка ...

чем дальше, тем сквернее становятса ваши коментарии,
но я не вижу приимуществ ОПП,
хотя вопрос стоял то изначально

Что на ваш взгляд, является необходимыми навыками/знаниями, чтобы сказать: «Я знаю ООП».

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 17:35

но я не вижу приимуществ ОПП,

моя жена медик — тоже не видит.
вполне понятно почему.

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

использующие видят, потому и используют — а вы вот нет. :)
Может вы не умеете его готовить?

так что по =живучести= продукта — марсаход поделка ...

ну это конечно. Вы то уже вона сколько пионеров воджеров запрограммировали! Честь и хвала!

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

вообще-то это был затасканный пример. можно было поговорить так же и об «опердне». или «PLM системе». или ECM. и т.п.

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

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

распределеннные системы, бегущие потом поверх — так же ООПшные. на тормозной джаве — толпа NoSQL БД и систем распределенных вычислений. Не только конечно на ней.
Так что и тут — поле для критики ООП большое. Тем более вам, с таким опытом создателя ПО для Пионеров и Вояджеров.

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

это да, ее сменит другая система, и опять ООПшная.

самому мне приходилось иметь дело с системали електронной торговли

и что, считали такты процессора и байты?

так что не надо мне раскзывать о таварах на сладах ...

так это ж здорово! Тогда вы реально можете предложить лучшие методики разработки ПО чем ООПшные.

Можете пока — тезисно?

и впихивать в 2к оперативки всю систему тоже доводилось

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

так что разнизу, как и общее прекрасно понимаю

хорошо.

Тогда что вам не понятно в факте:
ООП уже более 15-20ти лет — главная методика в разработке ПО для бизнеса?
Да и не только для бизнеса, а и для домашних пользоваталей?

И что предлагается другое — которое будет — лучше.

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

чем дальше, тем сквернее становятса ваши коментарии

это потому что я не понимаю причину и цель ваших вопросов.

Відповісти

Підтримати

Alex Voo 14.11.2013 19:03

Ну хорошо тогда продолжим :)

и что, считали такты процессора и байты?

конечно не считал, но в результате, когда систему нагузили, то пришлось сменить язык, концепцию и СУБД,
что вылилось в 2-3 месяца, зато потом перстраховались и 3-4 года не меняли

Тогда что вам не понятно в факте:
ООП уже более 15-20ти лет — главная методика в разработке ПО для бизнеса?

А сколько лет плавали в Индию вокруг Африки, даже Америку нашли ...
А потом, наверное не вдруг и не просто так, Суэцкий канал прорыли ;)
15 лет не показатель для истины ... и даже ведьм дольше жгли ...

это да, ее сменит другая система, и опять ООПшная.

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

есть очень много вещей, реализованых давно, на допотопных инструментах.
Я люблю приводить примеры из методов мат. моделирования. Есть очень мног ...
согласитесь тема обширная и весьма не простая
Практически все методы решения известны довольно давно и реализованы на фортране.
Благодаря этому фортран еще до сих пор дышит ...
Вот если бы вам пришлось переписать несколько библиотек с фартрана на более современный язык.
Скорее всего это был бы С или С++
Наврядли бы задействовали скриптовый язык.
Вы бы разве использовли ООП или перерозрабатывали формулы под обекты, как програмист вы бы сказали что не матиматик и скопировали бы данные и функцилонал,
тупо перепесав функции и привели бы кучу доказательств как это эфективно ...

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

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

это потому что я не понимаю причину и цель ваших вопросов.

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

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

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

А вот еще пример, точнее вопрос, я знаю кучу компиляторов насисаных на чистом С, а занете ли вы хоть один написаный на С++, наверно не спроста ...

получается что все просто, как в школе, знать дискриминант и уметь его выводить две разные вещи ...
так как если вы знаете дискриминант для многочлена Н-й степини включительно, это не гарантирует что вы знаете идля Н+1 -й, а вот если вывоить умеете :)

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

Я не призываю всех все писать самим

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

Ведь согдаситесь беря и используя библиотеку вы даже не проверяете как она работает, чито она не так делает, а ведь она скорее всего не версии 1,0, а версии х,у «дополненная и исправленная» ,
а ведь ее ктото использовал когда она была версии х-1,у-2 «урезаная и не исправленная» и их клиент был доволен :)

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

не нужно утрировать и заставлять меня отказатся от ОС с криками пиши свою ...

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

Відповісти

Підтримати

undefined pointer

undefined pointer 14.11.2013 21:12

перестраховались и 3-4 года не меняли

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

15 лет не показатель для истины

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

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

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

Я люблю приводить примеры из методов мат. моделирования.

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

Вы бы разве использовли ООП или перерозрабатывали формулы под обекты

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

но раз опять, то с формулами все как раз просто — нет смысла переводить прекрасно запись и работающую модель в другую запись и модель. особенно когда ООЯ — позволяет записать по старому.

и вот на примере таких задач обясните мне чем ООП лучше
я на примере «стрку перевернуть»

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

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

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

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

я знаю кучу компиляторов

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

не задумаватся как это все будет работать на многоядерных машинах

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

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

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

А реальных граблей хватаеи и яблоки мелкософта и интел с армом не безгрешны

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

Но во-первых — и тут при чем ООП, или неООП?
и во-вторых — а с чего вы так уверены что вы бы сделали — лучше?

не нужно утрировать и заставлять меня отказатся от ОС с криками пиши свою ...

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

Но если для использования пулов потоков

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

каким боком пул потоков относится к критике или одобрям ООП, ФП, коболу, хаскелю, форту с прологом?

Відповісти

Підтримати

undefined pointer 14.11.2013 21:16

перестраховались и 3-4 года не меняли

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

15 лет не показатель для истины

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

так как если вы знаете дискриминант для многочлена Н-й степини включительно, это не гарантирует что вы знаете идля Н+1

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

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

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

Я люблю приводить примеры из методов мат. моделирования.

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

Вы бы разве использовли ООП или перерозрабатывали формулы под обекты

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

но раз опять, то с формулами все как раз просто — нет смысла переводить прекрасно запись и работающую модель в другую запись и модель. особенно когда ООЯ — позволяет записать по старому.

и вот на примере таких задач обясните мне чем ООП лучше
я на примере «стрку перевернуть»

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

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

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

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

я знаю кучу компиляторов

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

не задумаватся как это все будет работать на многоядерных машинах

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

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

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

А реальных граблей хватаеи и яблоки мелкософта и интел с армом не безгрешны

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

Но во-первых — и тут при чем ООП, или неООП?
и во-вторых — а с чего вы так уверены что вы бы сделали — лучше?

не нужно утрировать и заставлять меня отказатся от ОС с криками пиши свою ...

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

Но если для использования пулов потоков

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

каким боком пул потоков относится к критике или одобрям ООП, ФП, коболу, хаскелю, форту с прологом?

Відповісти

Підтримати

Alex Voo 15.11.2013 10:09

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

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

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

А что массовость показатель эфективности?
Вы что знаете массу Стивов Джобсов, Билов Гейцев, Энштейнов :)
Массовость не показать совершенства, массовость — показатель ограниченности;

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

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

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

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

Но я напомнить вам осмелюсь, что говорим мы о ТЕХНОЛОГИЯХ и МЕТОДАХ строительства.
Удовльствие клиенту может оказать и женьщина професии очень древней и возможно в какойто момент он будет даже довольнее чем от результата вашего труда.

Відповісти

Підтримати

undefined pointer

undefined pointer 15.11.2013 10:56

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

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

и у вас скудные сведения о математике. в ней уже не редкость «красота» в виде 12 томов полного доказательства классификации простых конечных групп.

или 250 листов доказательства задачи Кеплера о наиболее плотной упаковке шаров — смешны на таком фоне.

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

Вы что знаете массу Стивов Джобсов, Билов Гейцев, Энштейнов :)

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

Массовость не показать совершенства, массовость — показатель ограниченности;

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

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

качество, согласно ISO это соотношение свойств к стоимости.
рестарт сервера удовлетворяющий всех при стоимости разработки Х — качественное решение. не требующее рестарта решение для при прочих равных при стоимости 10*X — НЕкачественное решение.

А вы утвеждаете что метод ваш,

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

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

говорим мы о ТЕХНОЛОГИЯХ и МЕТОДАХ строительства.

именно. Перефразируя Страуструпа
технологии и методы деляться на две группы: те которые ругают и те которыми никто не пользуется.

Удовльствие клиенту может оказать и женьщина професии очень древней

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

еще раз извините, мне скучно рассказывать вам прописные истины.

Відповісти

Підтримати

Alex Voo 15.11.2013 15:49

и веками писать совершенную программу.

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

качество, согласно ISO это соотношение свойств к стоимости.

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

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

Відповісти

Підтримати

undefined pointer

Alex Voo 11.11.2013 10:54

Что на ваш взгляд, является необходимыми навыками/знаниями, чтобы сказать: «Я знаю ООП».

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

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

Відповісти

Підтримати

Alexandr Gavriluk 10.11.2013 15:14

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

Тогда становится вполне ясно что байт это объект, подматрица это тоже объект, линия в коэффициентах — тоже объект, главное воспринимать их такими, даже если они не описаны как class.

Відповісти

Підтримати

anonymous 09.11.2013 20:11

-

Відповісти

Підтримати

anonymous 09.11.2013 20:08

-

Alexandr Gavriluk 07.11.2013 18:27

В некоторых случаях ООП просто не работает. Поэтому куча кода написана как методы
public static
protected static

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 07.11.2013 20:19

В некоторых случаях ООП просто не работает. Поэтому куча кода написана как методы
public static
protected static

Работоспособность ООП тут не при чем. Кучи кода со статками связаны, в большинстве, с мышлением. Так уж сложилось что __обучают__ программированию, в основном, на процедурной парадигме.
А сами статики как раз закрывают недостатки/неоднозначности __конкретных языков и их стандартных библиотек__, а не парадигмы в целом. Те же фабрики, про которые вы упомянули, это решение проблемы соединения аллокации и инициализации объекта и еще некоторых мелочей. Классы типа СтрингУтилс — это решение проблем вызванных реализацией класса Строка как финального.
.
Но самое забавное тут другое. То что вы написали статик не значит что вы перешли в процедурный стиль, поскольку статик — это такая же отправка сообщения объекту, так как класс — это такой же объект.

Відповісти

Підтримати

Alexandr Gavriluk

Ще 1 коментар

Alexandr Gavriluk 08.11.2013 02:49

Если так смотреть то байт — это тоже объект.

Відповісти

Підтримати

Stanislav Sklyarov 07.11.2013 11:48

Три стадии знания ООП:
1) Вы не знаете, как использовать ООП.
2) Вы знаете, как использовать ООП.
3) Вы знаете, как не использовать ООП.
Лично я сейчас пишу в классическом стиле «алгоритмы+данные», так проще тестировать. Отдельно классы с данными без логики, отдельно классы с логикой без данных. Никакой инкапсуляции, полиморфизм только через интерфейсы, наследование крайне редко, и то, больше делаю упор на замыкания. Я не работаю с 23-летними сеньорами и могу себе позволить так писать, лол, а вот коллегам в лидерах рынка приходится тяжко.

Відповісти

Підтримати

Grez 06.11.2013 21:13

Кстати, что еще вспомню в контексте «паттерны наше все», так это то, что когда речь заходит об дубликации кода, то любая логика и здравый смысл полностью пропадает из головы любого девелопера :-)
Не раз был свидетелем ситуации аля три _почти_ одинаковых куска кода, скажем по 100 строчек каждый, старанием умов мира сего, «легко» превращаются за 20+ классов различных конфигураций, фектори, репозиториев, адаптеров, стратегий (стратегия — наше фсе!) и прочего, что сам черт ногу сломит.
Причем у меня есть сомнения, что ФП тут каклибо спасет... просто будут вместо фектори, адаптеров и стратегий повсеместно использовать каррирование, монады, и метапрограммирование, что сам черт ногу сломит.

Відповісти

Підтримати

Ivan Pomidorov 06.11.2013 23:32

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

Відповісти

Підтримати

Grez

Sergii Surskykh Software Engineer 07.11.2013 11:14

Спагетти и «пахлава + Over Oriented Programming» — это две крайности, истина где -то посередине, исходя из задачи.
Мыслить сугубо паттернами — это все равно что мыслить сугубо компонентами Delphi или аналогами — Nuget пакетами в C# или одним из десятка JS фреймворков.
Вписывается инструмент в задачу — значит его и используем.

Відповісти

Підтримати

Grez

Ще 2 коментарі

Grez 07.11.2013 11:34

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

Відповісти

Підтримати

Sergii Surskykh

Sergii Surskykh Software Engineer 07.11.2013 11:39

Да, Вы правы, языком трындеть — не мешки ворочать.
Ибо грузят дедлайнами, не дают, ироды, творить высокое искусство, по SOLID, GRASP, Фаулеру, Банде четырех и пр.
Приходится иногда отбиваться спагетти.
Как по мне — так спагетти лучше чем пахлава, ее легче рефакторить

Відповісти

Підтримати

Grez

Саша Ковалев 09.11.2013 00:20

Как вспомню, когда нужно прикрутить запрос + логику и есть +100500 хранимок , а нет репозиториев, объекты создаются через поля, прилетают нулы, «недособранные обрезки» ,возможности расшириться нормально нет, возможности ясно и понятно описать бизнес-процесс ЯП нет — ну вас нафиг с вашими «тремя строчками и всё работает». «Ясно и понятно читаемый код гораздо важнее, простоты его написания». Думаю, мнение Макконела, что-то ещё значит в мире разработки ПО.
И спагетти + god-object, которое вырастает из «3х простых строчек» и «вот там подправить и дописать» это худшая крайность для всех, кроме вас (того, кто писал эти строчки). Не умеешь пользоваться патернами? так пойди и выучи их для начала, дабы не лепеить лишнего. Глаз мозёлят 5 лишних классов и 10 методов по 5 строк? А всем остальным взрывают мозг 300 строк в одном классе и скрип зубов при расширении этого говнкода.

Відповісти

Підтримати

Grez

Ще 37 коментарів

Bogdan Shyiak SE or Dev 09.11.2013 00:37

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

Вот кстати, «выучить» — это совсем не метод, как показывает практика, ибо «выучив» люди начинают их лепить куда попало, а из этого и получается «20+ классов различных конфигураций, фектори, репозиториев, адаптеров, стратегий».
Мое, ИМХО, что книги про шаблоны проектирования надо давать только после достижения инженером некоторой степени __зрелости__ (не опыта, а именно зрелости), и он обязан сначала немного поработать без этих знаний, чтобы понять для чего эти паттерны нужны, скорее всего большую их часть он «придумает» сам (это уже не столько про зрелость, сколько про опыт).

Відповісти

Підтримати

Саша Ковалев

anonymous 09.11.2013 00:47

-

Саша Ковалев 09.11.2013 00:51

подберите любое ёмкое слово, которое бы отражало:
знать названия, знать что делают, знать почему это делают, уметь реализовать, знать когда реализовать и знать — какие есть алтернативы и замените слово «выучи». Я соглашусь.
Да, я тоже считаю, что он должен поработать без этих знаний. Но нужно чтобы он поработал на проекте, гже это применяется уже а потом на том, где этого нет. А то часто бывает,что не работал ни разу на проекте, где шаблоны в плюс идут, потому что их правильно реализовали и там где надо и код расширяется на ура, потому и не любит шаблоны...или просто лень разобраться.

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 09.11.2013 00:57

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

Повторяю:

знать названия, знать что делают, ... какие есть алтернативы и замените слово «выучи».

Это как раз то к чему надо допускать с определенного уровня зрелости

знать почему это делают, уметь реализовать, знать когда реализовать

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

Відповісти

Підтримати

Саша Ковалев

Саша Ковалев 09.11.2013 01:00

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

Відповісти

Підтримати

anonymous 09.11.2013 01:19

-

anonymous 09.11.2013 00:44

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

Відповісти

Підтримати

Саша Ковалев

Bogdan Shyiak SE or Dev 09.11.2013 00:48

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

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

Відповісти

Підтримати

anonymous 09.11.2013 00:52

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 09.11.2013 01:02

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

Так мо и фабрику с декоратором оставим, а вот визитора и бридж уберем? :)

Відповісти

Підтримати

anonymous 09.11.2013 01:18

-

Саша Ковалев 09.11.2013 00:55

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

Відповісти

Підтримати

anonymous 09.11.2013 01:14

Да я кагбэ уже лет 10 в курсе, что токое эти ваши паттерны. А потом я познакомился с хаскелем, и узрел, что это замыкания и ФВП, только под разными именами. Самые очевидные примеры: колбеки, команды, шаблонные методы, фабрики.

Відповісти

Підтримати

Саша Ковалев

Grez 09.11.2013 01:46

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

Відповісти

Підтримати

anonymous 09.11.2013 02:07

У чистых ФЯ свои проблемы. Во-первых, ввод-вывод требует или императивности, или монад. Во-вторых, в остальных частях кода часто получается меньше, так что *большие* системы отсутствуют. В-третьих, кровавый интерпрайз по историческим причинам любит жабу и прочий кобол.
Я ж не сказал, что надо обязательно писать на хаскеле. Лично я на сишнике пишу. За эрланг можно Макса Сохацкого расспросить.

Відповісти

Підтримати

Grez

reality_hacker 09.11.2013 04:19

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

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

Відповісти

Підтримати

Саша Ковалев 09.11.2013 02:31

В курсе-то это понятно что вы именно в курсе, а сами из тех, кто паттерны так и не принял и не полюбил и, видимо, научился пользоваться , хоть 20 лет спустя. Я тоже встречал архитекторов, которые мне простыни кода сокращать предлагали регионами вместо необходимого рефакторинга классов. А может, опыт Delphi не отпускает? Или просто задачи ваши были узкоспециализрованные без проблем(общий код, сложная и перегруженная модель предметной области), описанных в ответах к основной теме? Я, возможно, и не узерл что Фабрика это оказывается замыкание с бантиком,

— это функция, в теле которой присутствуют ссылки на переменные, объявленные вне тела этой функции и не в качестве её параметров (а в окружающем коде)

возможно нужно тоже хаскел с собой познакомить, но сами замыкания сознательно только в javascript применял, понимая что без это Г. не обойтись. А вот колбеки, это нефига не замыкания исходя из определения. Угу. Хотя, кажутся очень похожими, но всё же это указатели, передаваемые через аргументы

Відповісти

Підтримати

anonymous 09.11.2013 04:30

а сами из тех, кто паттерны так и не принял и не полюбил

Я не религиозен. «Принять» — это не из моего репертуара.

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

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

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

Відповісти

Підтримати

Саша Ковалев

Саша Ковалев 09.11.2013 12:33

Да, это нормально считать всех джунами. Это тоже определённая стадия, которую ещё предстоит пройти. Ещё любят стадии выделать: джун до про чтения ГОФ, джун после прочтения ГОФ. И отказник от ГОФ ... таковыми себя сеньоры считают. Но есть ещё 4ая стадия, когда паттерны не задумываясь и как-то всё само, на автоматизме получает правильно. Но для этого важно в отказниках не оказаться.

Так что, фабрика это замыкание или не замыкание?
И вы, часом, вот такую шнягу:
method_ab(a,b), method_abc(a,b,c), method_a(a)
полиморфизмом не называете? А то так любят называть в языках типа php, где его отродясь(до 5 версии точно) не было и быть не могло, но в угоде моде на ООПешность языков. А признать что полиморфизм язык не поддерживает что-то не позволяет.

>>

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

Это не костыльные языки, это просто НЕ замыкания. Это может быть очень похижая функциональность, но это не замыкание. В случае замыкания, скажем в javascript или C# я могу в теле «внутренней» функции работать с внешним куском тела другой функции. А делегаты это, когда внутренняя функция вызывает внешнюю, причем ту, что передана с указателем через аргумент.
вот правильный пример замыкания в C# (тут есть и делегаты и замыкания):
www.rsdn.ru/...e_in_Csharp.xml
Там в анонимный метод попадает переменная из внешнего окружения.
А есть ещё куча неправильных, когда простые колбеки называют замыканием.

Відповісти

Підтримати

anonymous 09.11.2013 16:04

Да, это нормально считать всех джунами. Это тоже определённая стадия, которую ещё предстоит пройти.

О, да у Вас будапешт! :)

Ещё любят стадии выделать: джун до про чтения ГОФ, джун после прочтения ГОФ. И отказник от ГОФ ... таковыми себя сеньоры считают.

Ну что Вы, есть сеньоры — фонаты ГОФ-а. Я это не отрицаю, а вот Вы, похоже, отрицаете?

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

А вот эта часть на 100% верна. Действительно, существует такая стадия. И я предлагаю решение, как достичь её скорее, забивая голову меньшим количеством мусора. Ведь не «паттерны ГОФ — не нужны», а «изучение паттернов ГОФ — не нужно».

Так что, фабрика это замыкание или не замыкание?

Замыкание. В общем случае, все объекты (данные + методы) — замыкания, если Вы вдруг не знали :)

И вы, часом, вот такую шнягу:
method_ab(a,b), method_abc(a,b,c), method_a(a)
полиморфизмом не называете?

Нет.

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

Это уже *использование*, *вызов* делегата. А при создании он вполне себе захватывает ссылки на окружающие переменные — совсем как замыкание.

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

Очевидно (см. цитату), делегат C# — частный случай замыкания. Из-за каких-то нюансов в архитектуре .Net их приходится различать.

вот правильный пример замыкания в C# (тут есть и делегаты и замыкания):
www.rsdn.ru/article/csharp/Closure_in_Csharp.xml
Там в анонимный метод попадает переменная из внешнего окружения.

Всё верно. И будь на месте «ThreadPool.QueueUserWorkItem()» какой-нибудь другой метод, он мог бы даже проигнорировать свои параметры, и делегат не был бы вызван.

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

Что такое «простой колбек», и чем он отличается от «непростого»?

Відповісти

Підтримати

Саша Ковалев

Саша Ковалев 09.11.2013 16:29

«изучение паттернов ГОФ — не нужно».

Я уже писал коллеге — подберите нужное слово для всех тех понятий и предложите.

А при создании он вполне себе захватывает ссылки на окружающие переменные

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

В общем случае, все объекты (данные + методы) — замыкания, если Вы вдруг не знали :)

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

Відповісти

Підтримати

anonymous 09.11.2013 01:15

То, что не противоречат — факт. Но что проще выучить, две универсальные сущности, или целый пучок?

Відповісти

Підтримати

Саша Ковалев

Саша Ковалев 09.11.2013 02:12

Пучок? Репозиторий, фабрика, Сервис? Ну ещё стратегия для алгоритма. Для доменной логики более чем достаточно.

Відповісти

Підтримати

anonymous 09.11.2013 04:20

Ух ты! Оказывается, «знать паттерны» — это вот эти вот 4? Ни шаблонные методы, ни фасады, ни декораторы, ни, прости Г-ди, визиторы с синглтонами, на самом деле не очень-то нужны? Ну ок.
"Весело у вас тут"©

Відповісти

Підтримати

Саша Ковалев

Саша Ковалев 09.11.2013 12:36

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

Відповісти

Підтримати

anonymous 09.11.2013 15:28

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

Я тупой, я не понимаю. Объясните, а?

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

Через «две сущности» можно успешно реализовать ВСЕ СЛОИ. Почувствуйте разницу. Расскажите, для каких не-велосипедов их будет мало.

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

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

Відповісти

Підтримати

Саша Ковалев

Саша Ковалев 09.11.2013 16:35

софистика в руках «ребят с рабочего района» это гремучая смесь, даже в интернете.

Відповісти

Підтримати

anonymous 10.11.2013 17:53

-

anonymous 10.11.2013 17:58

-

anonymous 10.11.2013 18:21

-

Grez 09.11.2013 01:33

«Ясно и понятно читаемый код гораздо важнее, простоты его написания»

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

И спагетти + god-object, которое вырастает из «3х простых строчек» и «вот там подправить и дописать» это худшая крайность для всех, кроме вас (того, кто писал эти строчки). Не умеешь пользоваться патернами? так пойди и выучи их для начала, дабы не лепеить лишнего.

Если способ решения всех задач человеком является спагетти + god-object, то такому человеку знания паттернов не факт что помогут.

Глаз мозёлят 5 лишних классов и 10 методов по 5 строк? А всем остальным взрывают мозг 300 строк в одном классе и скрип зубов при расширении этого гвнкода.

Допускаю, что дело субьективное, но мне проще иметь дело с класамми в 300 строк, даже если это конкретный гвнокод (за вычетом, наверное, какойто хитрой математики и алгоритмов), чем с полетом абстрактной мысли на 20+ классов.

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

Відповісти

Підтримати

Саша Ковалев

Саша Ковалев 09.11.2013 02:21

просто если знать концепцию в целом, например DDD а потом видеть тот или иной паттерн, то всё встаёт на свои места. Ведь по сути модель предметной области примерно так строиться:
1. вызывали одну сущность — репозиторий
2. создали вторую — фабрика или билдер
3. Возможно инициализировали правило для этих сущностей в виде спецификации.
4. Вызвали сервис, обработали обе сущности — сервис + стратегия или что-то личное, будь то композитный метод и т.п.
5. сохранили сущности. — репозиторий
Всё прекрасно раширяется, изменяется и, главное, тестируется!
Да, безусловно для логики в 5 сущностей это излишнее, как и личшние запросы к БД и ОРМ которая в целом для этой абстракции и существует. Но когда знают про первое (про сущности и репозитории) и не делают 2,3 и 4, то тогда и получается каша. А то все oRM в лице EF code-first или fluent nhibernate любят внедрять. А дальше сущностей, которые со временем становятся всё теми же уродскими ActiveRecord сами себя готовящими , дело не доходит. А это крайне не правильно для сложной бизнес-логики.

Відповісти

Підтримати

Grez

Grez 09.11.2013 13:29

Я не спорю, что если нормально владеть, и систематично применять то же ДДД, то картина вроде как должна получиться красивая. Но практика несколько иная:
-О ДДД вообще никто не знает, и читать не хочет (кстати, я вам могу предложить на следующую сходку ДОУ подготовить доклад-призентацию о том что это такое, и какие бенефиты оно дает).
-О системе, и какая там внутри архитектура тоже никто не знает, и знать не хочет.
-Каждый тупо лепит то что считает нужным.

Я за что всю рабочую жизнь безуспешно «„боролся“», так это за изоморфность системы: чтобы архитектура, дизвйн и стилистика решений внутри системы были везде одинаковыми, каким бы это гвнокодом небыло. Тогда с «этим» можно чтото сделать. Но на практике каждый новый программист (а часто и старый), просто тупо наворачивает новый паттерновый «велосипед», который решает одну задачу, в одном месте.
В результате система — бессвязный набор велосипедоы тут и там, которые вцелом невозможно обхватить вообще никак. Зато у нас паттерны и ООД. А потом нород жалуеться по форумам о том как его этот ООД достал.

Відповісти

Підтримати

Саша Ковалев

Саша Ковалев 09.11.2013 15:30

кстати, я вам могу предложить на следующую сходку ДОУ подготовить доклад-призентацию

Спасибо. Но я живу не в Киеве :) На локальном уровне я делал подобный доклад. Главная проблема, как вы верно заметили , в том, что никто ничего не хочет, в том числе и читать и узнавать. И потом по форумам жалуется...

Відповісти

Підтримати

Grez

Roman Brunets Программист в контрактор 10.11.2013 00:25

Всё прекрасно раширяется, изменяется и, главное, тестируется!

Вы даже не представляете, какой силы говнокод вы только что написали. :facepalm:

Відповісти

Підтримати

Саша Ковалев

Grez 10.11.2013 12:35

А вы сами то ДДД читали?
И вообще, прояснить свою точку зрения слабо ?

Відповісти

Підтримати

Саша Ковалев 10.11.2013 12:45

«не читал но глубоко осуждает» или «видел я этот ваш ДДД, (не осилил) потому и укоряю сию бесовщину» Только чтением там не обойтись: как привыкли некоторые посмотреть на stackowerflow как прикрутить ORM или наговнякать репозиторий, а зачем и почему не ведомо. Там практика нужна, которая сильно рушит старые устои моделирования и дизайна.

Відповісти

Підтримати

Grez

Roman Brunets Программист в контрактор 10.11.2013 13:27

А вы сами то ДДД читали?

Читали??? Вы серьезно?

И вообще, прояснить свою точку зрения слабо ?

Декомпозиция модели предметной области с помощью никак не связанных с предметной областью паттернов проектирования это абсолютный говнокод.

Відповісти

Підтримати

Grez

Саша Ковалев 10.11.2013 14:32

1) Декомпозиция = моделирование (предметной области)? o_O
2) Паттерны проектирования должны быть связаны с конкретной предметной областью? Это вы серьёзно?!
facepalm

Відповісти

Підтримати

Roman Brunets Программист в контрактор 10.11.2013 14:47

1.Нет.
2.Нет.

ЗЫ Вот о чем можно говорить с такими людьми?

Відповісти

Підтримати

Саша Ковалев

Саша Ковалев 10.11.2013 19:05

1. Именно это логически вытекает из высказывания выше
2. Именно это пчти процитировано высказыванием выше:
"

Декомпозиция.. с помощью... несвязанных с ... предметной областью паттернов...

"
и моё:

Паттерны.. должны быть связаны с... предметной областью?

PS точно не о чем.

Відповісти

Підтримати

Grez 10.11.2013 17:27

Декомпозиция модели предметной области с помощью никак не связанных с предметной областью паттернов проектирования это абсолютный гвнокод.

Веселые персонажи, такие веселые :-)
Тут, для развития, два вопросо:
Почему вы считаете данный подход «абсолютным гвнокодом»?
И какое, вообще, описаный вами подход имеет к ДДД ?

Відповісти

Підтримати

Саша Ковалев 10.11.2013 12:46

иногда лучше молчать, Роман, делая вид незнающего,чем говорить, делая вид знающего.

Відповісти

Підтримати

Alex Voo 06.11.2013 18:16

Что на ваш взгляд, является необходимыми навыками/знаниями, чтобы сказать: «Я знаю ООП».

абстрагирование
Может «немного перегну», но приведу пример уравнений Максвелла в векторном виде для физики

Буду удивлен если первый коммент будет по теме и не будет содержать вброс про ФП :)

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

Відповісти

Підтримати

Апполинарий Эмануилович 06.11.2013 12:24

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

Відповісти

Підтримати

anonymous 06.11.2013 15:52

Опа, гавнокод стайл!!

Відповісти

Підтримати

Апполинарий Эмануилович

Ще 1 коментар

Апполинарий Эмануилович 06.11.2013 16:45

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

Відповісти

Підтримати

Sergii Surskykh Software Engineer 05.11.2013 23:23

Может это все следствия расцвета все тех же 23-летних синьоров?

Мрачно обалдел от следующего на собеседованиях с ними:
1) В: Что такое делегат в C#?
О: В общем виде, это указатель на функцию
В: Ну что Вы? Делегат — это делегат.
2) Extensions в C# преподносилось как одно из выдающихся его достижений, сравнимых с Фаустом Гете.
3) TPL преподносилась, как панацея от всех бед, разруливающая deadlock и race condition одним фактом своего использования.

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

Сейчас такое подлечиваю юнит тестами, ибо без них боюсь рефакторить;)

Відповісти

Підтримати

anonymous 06.11.2013 17:07

-

Відповісти

Підтримати

Sergii Surskykh

Ще 3 коментарі

Sergii Surskykh Software Engineer 06.11.2013 17:25

Delegates are like C++ function pointers but are type safe.

Я был бы рад такому уточнению от интервьювера;)

Відповісти

Підтримати

Дмитро 07.11.2013 10:09

зачем же искать 23х летнего синиора на преподавательскую позицию?

Відповісти

Підтримати

Sergii Surskykh

Sergii Surskykh Software Engineer 07.11.2013 11:08

Я не искал 23-летнего синьора, это меня собеседовали 23-летние «синьоры», сами себя туда втулившие;)
К тру 23-летних синьорам у меня претензий нет (а есть такие), как и к тру 67-летним «динозаврам».

Відповісти

Підтримати

Саша Ковалев 09.11.2013 00:28

научите как объяснить клиенту, что нужен рефакторинг и срочно и что даже без тестировщиков кроме как тестами продукт в нормальном состоянии уже скоро поддерживать нельзя будет?
На всё ответ — мы маленькая команда (2 манагера, 3 разработчика), нам нужно пилить фичи для" взлёта"

Відповісти

Підтримати

Sergii Surskykh

Ще 3 коментарі

Sergii Surskykh Software Engineer 10.11.2013 17:14

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

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

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

Відповісти

Підтримати

Саша Ковалев

Саша Ковалев 10.11.2013 19:39

Да всё способ решить задачу, просто во всём нужно система. А если системы нет или какие-то основные компоненты из неё исключены наступает хаос. Клиент всегда кивает, что понимает зачем это надо, но ему жалко денег(=времени). Он же думает, что раз ему продали разработчика и сказали, что всё будет круто, то этот разработчик по моновению палочки напишет сразу качественный код без ошибок, а иначе он плохой разработчик. Большинство же, когда делает ремонт не закладывается на то, что стены придётся перештукатуривать по 2-3 раза.... все хотят с первого раза.

Відповісти

Підтримати

Sergii Surskykh

Sergii Surskykh Software Engineer 11.11.2013 11:28

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

Відповісти

Підтримати

Саша Ковалев

Max Dzyubenko 04.11.2013 23:02

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

А вообще, нынче, к ОО-коду пошли всякие специальные требования. Как то, 1) минимальная стоимость обслуживания (т.е. рукописного кода должно быть, как можно меньше) 2) максимальная платформонезависимость (абстрагирование от БД, ГУИ, мыши/клавиатуры, итп) 3) максимальная независимость реализации подсистем/классов друг от друга («контрактное программирование») 4) многопоточность (акцентирование не на объектах предеметной области, а на задачах). Соответственно меняются и подходы.

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

Відповісти

Підтримати

undefined pointer 05.11.2013 09:39

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

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

пару наспех примеров:
1.
а) по самим объектам: фрукт- яблоко — Антоновка

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

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

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

P.S
justy_tylor: В программирование тянут отовсюду. Из разных областей математики, <b>из махровой аристотелевщины (object oriented programming)</b>, а временами вообще из труб и жидкостей (flow based programming).

в том и беда применения ООП — аристотелевщина. Номинализма не хватает.

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

утрировано говоря — либо бросайте ООП и идите в ФП, где математика 20го века,
либо — начните наконец философствовать более современно, когда применяете ООП.

Каким должно быть ООП? — «номиналистким». а пока оно — «аристотелевское»

Відповісти

Підтримати

anonymous 04.11.2013 21:46

-

anonymous 04.11.2013 21:46

-

anonymous 04.11.2013 22:05

-

Grez 04.11.2013 18:24

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

Відповісти

Підтримати

Ivan Pomidorov 04.11.2013 18:26

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

Відповісти

Підтримати

Grez

Ще 6 коментарів

Grez 04.11.2013 18:30

это если передержать :-D

Відповісти

Підтримати

Dmytro Lapshyn Solution Architect 05.11.2013 17:43

Ну ладно вам :) Большинство из тех, кому сейчас 30-35 лет, начинали изучать программирование как раз с процедурного стиля.

Відповісти

Підтримати

Ivan Pomidorov 05.11.2013 17:55

То-то, проекты написанные в начале двухтысячных на джаве такое Г.

Відповісти

Підтримати

Blitz Senior .net Developer / Architect 05.11.2013 18:26

То что Джава начала двухтысячных — полное Г не считается?

Відповісти

Підтримати

Ivan Pomidorov 05.11.2013 18:38

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

Відповісти

Підтримати

Blitz

Grez 05.11.2013 21:46

Основная проблема вообще, это то что
«чтото более мение слепленное» != «ваши личные предпочтения в текущий момент времени».

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 04.11.2013 18:28

Любопытно, а зачем вам так важен ответ на этот вопрос?

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

Відповісти

Підтримати

Grez

Sergii Surskykh Software Engineer 05.11.2013 23:06

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

Відповісти

Підтримати

Grez

anonymous 04.11.2013 18:14

Может это все следствия расцвета все тех же 23-летних синьоров? Человек много прочитал, использовать еще не научился, а хочетсо сделать все как взрослые дяди.

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

Відповісти

Підтримати

Sergii Surskykh Software Engineer 05.11.2013 23:10

Знаю тру 24-летнего синьора.
Искренне любя продукцию Майкрософт — капитализирует занаия еще в Джава, дабы не быть зависим от технологии.
Нигде не видит «серебрянной пули», постоянно учится, ни на кого свысока не смотрит.
Хобби — рисование фракталов;)

Відповісти

Підтримати

Ще 12 коментарів

anonymous 06.11.2013 09:32

23 и 24 примерно одно и то же, не видит серебрянную пулю — это как бы просто мидл
Java и C#..... как то не очень разносторне
в чем выражена его тру сеньорность? может он гуру Haskell, Erlang, Clojure в придачу к основному вектору деятельности? может он делал какойто крупный вклад в опенсорс комьюнити? или может приведете общий пример какойнибудь крупной системы которуе он сделал, или ключевую часть в ней, или проектировал дизайн, и она в итоге работает бронебойно?

Відповісти

Підтримати

Sergii Surskykh

Sergii Surskykh Software Engineer 06.11.2013 10:26

23 и 24 примерно одно и то же

Можно не поумнеть и к 40 и продолжать иметь непоправимые ошибки в ДНК.

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

Это по какому счету? Фейсбука? Синьоров по должности, ее видевших — встречал неоднократно.

в чем выражена его тру сеньорность?

Правильное мировоззрение и направление движения, с ним можно обсуждать и решать любую задачу. Крайне хороший стержень, мясо ниже — нарастет.

может он гуру Haskell, Erlang, Clojure в придачу к основному вектору деятельности? может он делал какойто крупный вклад в опенсорс комьюнити? или может приведете общий пример какойнибудь крупной системы которуе он сделал, или ключевую часть в ней, или проектировал дизайн, и она в итоге работает бронебойно?

Вы описываете Tech Leada или Arhitecta в нынешней «табели о рангах» или гуру типа Фаулера или Ханта.

Відповісти

Підтримати

anonymous 06.11.2013 10:34

Это по какому счету? Фейсбука? Синьоров по должности, ее видевших — встречал неоднократно.

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

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

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

Вы описываете Tech Leada или Arhitecta в нынешней «табели о рангах» или гуру типа Фаулера или Ханта.

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

Відповісти

Підтримати

Sergii Surskykh

Sergii Surskykh Software Engineer 06.11.2013 10:55

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

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

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

Это ближе к лиду, что у нас, что за рубежом.

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

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

Відповісти

Підтримати

anonymous 06.11.2013 10:59

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

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

то есть ваш знакомый сеньор в полной мере обладает этими качествами?

Відповісти

Підтримати

Sergii Surskykh

Sergii Surskykh Software Engineer 06.11.2013 15:00

то есть ваш знакомый сеньор в полной мере обладает этими качествами?

Полагаю, да, выгодно выделяется на фоне сверстников с некоторыми «ошибками в ДНК», эти ошибки мало зависят от возраста.
У меня в возрасте 23-24 и даже намного позже они были.
Причем на хвалебные слова о синьорстве подсовывает картинку с «си, синьор»;)
Что выгодно отличает его от собеседоваших меня прочих 23-летних синьоров, но самих себя в туда определивших.

Відповісти

Підтримати

anonymous 06.11.2013 15:50

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

Відповісти

Підтримати

Sergii Surskykh

Sergii Surskykh Software Engineer 06.11.2013 16:32

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

Нам давно пора избавляться от комплекса местечковой неполноценности;)
Рекрутеры, 23-летние «синьоры», отвращение к баззвордам + впихиваемым корпоративным «ценностям», неприятие спускаемых сверху Agile metodologies, и пр. — это проблемы не только наши — но и всего IT мира.
Средняя температура по палате может несильно отличаться, но это не сугубо наши проблемы.

Відповісти

Підтримати

Ivan Pomidorov 06.11.2013 19:28

неприятие спускаемых сверху Agile metodologies

А есть альтернатива? Вот как бы Вы организовали работу оффшорной команды из 7 человек? Не троллю, действительно интересно.

Відповісти

Підтримати

Sergii Surskykh

Sergii Surskykh Software Engineer 06.11.2013 19:54

Ключевой момент — «спускаемых сверху» как маркетинговые фичи без каких либо объяснений с «так надо» и «так круто», вплоть до требования в технической вакансии «5+ лет Agile»

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

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

Ничего не имею против Agile методологий как таковых, равно как и Waterfall, все создано для своих условий.

Відповісти

Підтримати

Саша Ковалев 09.11.2013 00:43

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

>>

и она в итоге работает бронебойно

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

Відповісти

Підтримати

anonymous 09.11.2013 09:17

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

>>>

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

и где я утверждал об обязательности опен сорса?

А с каких пор у нас что-либо работает бронебойно?

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

Відповісти

Підтримати

Саша Ковалев

ScorpZ Lapshov C++/C# && other programmer в AMC Bridge 04.11.2013 16:14

Собственно вопрос:
Что на ваш взгляд, является необходимыми навыками/знаниями, чтобы сказать: «Я знаю ООП».

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

Відповісти

Підтримати

Beaver Green 04.11.2013 15:39

ООП, ФП, UML, паттерны ... Все это только инструменты. Для того, что бы их правильно использовать — их мало выучить, их надо понимать.
Т.е. главный вопрос должен быть не «Как?», а «Зачем?».
Зачем полиморфизм? Зачем наследование? Зачем SOLID? Зачем паттерны? Зачем вообще ООП или ФП?
У специалиста есть ответ на эти вопросы. Потому что он видел разницу на практике. Студент — теоретик будет только удивляться «нахрена это все напридумывали?».
Постараюсь коротко ответить на вопрос «Зачем?»: Бороться со сложностью! Потому что:
1. Предметная область сложная сама по себе (к сайтам — визиткам это не относится).
2. Человек может удержать в уме ограниченное количество информации.
3. Люди думают по-разному и не умеют обмениваться мыслями и знаниями «напрямую».
Собственно эти ограничения и порождают всякие методики, которые позволяют «съесть слона по кусочку» — т.е. свести сложную и запутанную предметную область к иерархии вложенных абстракций, которые человек способен «прожевать».
ООП популярно потому что это простая для понимания методика, имеющая аналогии с реальными вещами. Аналогии в ООП — реальные объекты (касса, магазин, продавец), аналогия для ФП ... на ум приходит разве что эквалайзер.
Кто считает ООП излишним и «перегруженным»? Смотрим на пункты 1-3. Это девелопер, который работает:
1. Над небольшой и несложной предметной областью (или простой частью большей области).
2. Пишет свой новый код и держит его в памяти, потому что работает с ним каждый день.
3. Минимально лезет в чужой код и имеет доступ к автору для консультаций.
Т.е. фактически работает на простом и удобном проекте уровня EASY ! А что бы познать силу ООП нужно попробовать как минимум HARD. Но можно еще попробовать NIGHTMARE: попасть внутрь огромного лабиринта запутанного кода с методами — монстрами, без компаса, карты и даже понимания что это было за приложение. После этого можно стать «инквизитором», который готов карать девелоперов за каждый метод длиной больше 10 строк, каждый публичный фиелд, каждый вложенный цикл или иф, каждый класс без интерфейса и т.д.

Відповісти

Підтримати

Ivan Pomidorov 04.11.2013 15:41

Но можно еще попробовать NIGHTMARE

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

Відповісти

Підтримати

Ruslan Shevchenko Researcher 04.11.2013 08:23

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

Відповісти

Підтримати

Alexey Mironchenko Security master, Senior Engineer в Ericsson LMI 04.11.2013 15:36

Тынц, плюсую.
Моделирование -> ООП,
Алгоритмы -> ФП.

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

P.S. Мультиагентные системы для тех, кто будет говорить, что алгоритмы все равно нужны там, где корректно использование ООП.

Відповісти

Підтримати

Ruslan Shevchenko

bsod 04.11.2013 00:09

Cargo cult же. Мне кажется, есть такие уровни проектов в этом отношении, на каждом из которых можно застрять навсегда:
1)Нет ритуалов, нет понимания — например, какой-нибудь типичный мелкий сайтик-магазинчик, просто пишем как пишется.
2)Есть ритуалы, нет понимания — как раз тот случай, люди уже хотят сделать хорошо, но пытаются для этого использовать в основном готовые рецепты. Детекторы: [синглтоны запрещены- это антипаттерн/static-методы запрещены, нужно писать синглтон]; [хранимые процедуры запрещены-вся логика должна быть в коде/максимум логики должно быть на хранимых процедурах-включая простейшие запросы]; [TDD для абсолютно любого кода] и подобные запреты/правила без исключений.
3)Есть понимание — когда есть знания и опыт в разных подходах, и они адекватно применяются в соответствии с одтельными задачами. Мне кажется, лучший способ сюда попасть — просто опыт работы в разных проектах 2-го типа, когда узнаешь, когда какой подход стреялет, а когда фейлит.

Відповісти

Підтримати

Alexey Kachayev CTO в Attendify 03.11.2013 23:19

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

Началось все давно — с простой идеи отказаться от оператора goto. Процесс отказа достаточно затянулся (было много адептов старого подхода), но в итоге это привнесло в программирование такую замечательную штуку как «модульность». Теперь код __нужно__ разделять на куски для переиспользования, и у нас для этого уже есть много подходов: функции / процедуры / модули / пакеты / сопрограммы / классы / тд. Разделять код оказалось просто, главное было начать.

Но затем стал другой вопрос: как разделенный код собрать в приложение? Тут появляется понятие composatibility, и подчеркну — именно composability (т.е. возможно __просто__ связать несколько участков кода в один) и есть ключевым вопросом, который в общем случае не так просто решить. Первый миф ООП, главное — разделить код на правильные куски, не верьте — главное суметь потом это собрать.

Composability функций очень высока, кроме side-effects случаев, отсюда исходит мощь и сила ФП. У классов в ООП — практически нулевая. И с «философской» точки зрения, и с чисто технической. Скрытый state внутри объекта, in-place mutability — худшее, что можно придумать с точки зрения попыток соединить два участка кода (под словом «соединить» можете читать также «протестировать», «перенести», «реиспользовать», «заменить»). Отсюда и появляются все эти паттерны, потому что объекты изначально «недружные» друг к другу нужно как-то уживать.

Вот есть у вас Еда и Собака. Может ли Еда скормиться Собаке? Или Собака может Еду съесть? Или нужен Человек, который Собаку накормит Едой? И где хранить информацию о том, что Еда может быть Съедена, а Собака Накормлена? Чем дальше в лес — тем злее дятлы. Тем толще книги о паттернах. И тем дальше вы от сути ситуации «еда −10, сытость +5».

Хотите разобраться в ООП — учите Haskell, или еще лучше ML (но на нем никто не пишет, поэтому будет скучновато). Посмотрите Camp/OCaml.

Відповісти

Підтримати

Roman Brunets Программист в контрактор 03.11.2013 23:25

Описанная проблема с «заучиванием и цитированием» GoF упирается в тот факт, что без паттернов писать на «ООП» невозможно.

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

ЗЫ С остальным, в принципе, согласен.

Відповісти

Підтримати

Alexey Kachayev

Ще 2 коментарі

Alexey Kachayev CTO в Attendify 04.11.2013 09:39

Да чушь собачья.

Give it five minutes, как говориться. Прежде чем начинать исключительно плодотворную эмоциональную дискуссию.

Банда четырех паттерны не выдумала, а описала и систематизировала. Поэтому до них писали код с теми же паттернами (местами лучше, местами хуже) — просто не знали как это все называется.

Відповісти

Підтримати

Sandro Zakusilov 04.11.2013 17:31

en.wikipedia.org/wiki/Pattern
ru.wikipedia.org/.../Систематизация

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

Так что,

Да чушь собачья.

EDIT:
Даже GoF вам скажет — нет имени, описания, назначения — нету паттерна.

Відповісти

Підтримати

Alexey Kachayev

Sergey Ponomarev Java & Grails Developer 03.11.2013 23:26

А что такое «in-place mutability»? Это тоже самое что и деструктивное присваивание?

Відповісти

Підтримати

Alexey Kachayev

Ще 1 коментар

Alexey Kachayev CTO в Attendify 03.11.2013 23:34

in-place mutability

возможность поменять значение по адресу памяти / указателю / названию property класса или даже set-методу (все описаное все равно сводится к пункту один). антоним immutability.

Відповісти

Підтримати

Sergey Ponomarev

Євген Козлов Front-end developer в SoftServe 03.11.2013 23:49

Вот есть у вас Еда и Собака. Может ли Еда скормиться Собаке?

предполагаю, это какой-то ~~баян~~ классический прием на тему «ООП — отстой»?

Відповісти

Підтримати

Alexey Kachayev

Ще 7 коментарів

Sergii Voloshyn Product Manager в DOU.ua 03.11.2013 23:58

Мне вспомнился этот топик:
dou.ua/...ums/topic/5647

Відповісти

Підтримати

Євген Козлов

Alexey Kachayev CTO в Attendify 04.11.2013 09:37

В таком случае у вас должен быть на него «классический» ответ. Или нет?

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 04.11.2013 09:54

“Предполагаю” не подсказало, что вижу это в первые?
Я уже как-то интересовался баталией на тему “ФП против ООП”.
Как на меня, сложно сказать проще:

When you anticipate a different kind of software evolution:
* Object-oriented languages are good when you have a fixed set of operations on things, and as your code evolves, you primarily add new things. This can be accomplished by adding new classes which implement existing methods, and the existing classes are left alone.
* Functional languages are good when you have a fixed set of things, and as your code evolves, you primarily add new operations on existing things. This can be accomplished by adding new functions which compute with existing data types, and the existing functions are left alone.
-------------------------
When evolution goes the wrong way, you have problems:
* Adding a new operation to an object-oriented program may require editing many class definitions to add a new method.

* Adding a new kind of thing to a functional program may require editing many function definitions to add a new case.

Что ж до меня, то я бы таки делал через функции. Что в контексте ОО-языков, известных мне, обернулось бы глобальной свайлкой “Мир” со статическими методами, среди которых кормить(iEatable, iEater), как-то так. Внутри метода посылал бы событие еде “тебя едят”, а едоку — “ты ешь то-то”. Или вызывал бы соответствующие методы напрямую.

Відповісти

Підтримати

Alexey Kachayev

Alexey Kachayev CTO в Attendify 04.11.2013 09:59

ФП против ООП

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 04.11.2013 10:01

то есть, абсолютно никаких преимуществ друг перед другом?! что, правда?!

ФП vs. ООП — это разные «весовые категории»

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

Відповісти

Підтримати

Alexey Kachayev

Kirill Sablin Developer 04.11.2013 10:14

на чем акцент, на объектах или на действиях

это не разница между ФП и ООП:)

в одном коде это будет сложно совместить

посмотрите гибриды, например, js и scala.

Відповісти

Підтримати

Євген Козлов

Alexey Kachayev CTO в Attendify 04.11.2013 10:17

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

Lambda calculus VS. turing machine — вычислительные системы. Декларативное и императивное программирование — формализированные концептуальные подходы, базирующиеся на соответствующей вычислительной моделе (моделях). ООП — некая императивная парадигма, попытка навести порядок (одна из многих, вряд ли самая удачная).

Можно сравнивать ООП c F-coalgebra, или с ADT (с existential types) или даже с System-F (в разрезе records + subtype / parametric polymorphism). Но этого никто не делает.

Відповісти

Підтримати

Євген Козлов

Bogdan Shyiak SE or Dev 04.11.2013 00:00

Описанная проблема с «заучиванием и цитированием» GoF упирается в тот факт, что без паттернов писать на «ООП» невозможно.

Неплохой врос. От только у вас такое же понимание паттернов как и у тех кто требует цитирования ГоФ, для вас они независимая сущность (судя по вашей фразе), а не просто «best practices».

Скрытый state внутри объекта, in-place mutability

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

Composability функций очень высока, кроме side-effects случаев, отсюда исходит мощь и сила ФП. У классов в ООП — практически нулевая. И с «философской» точки зрения, и с чисто технической.

Можно подробнее почему у объектов (классы, на мой взгляд, не обязательная составляющая ООП) composability нулевая? Или вы все про те же постоянно мутирующие объекты?

Відповісти

Підтримати

Alexey Kachayev

Ще 2 коментарі

Alexey Kachayev CTO в Attendify 04.11.2013 09:50

От только у вас такое же понимание паттернов как и у тех кто требует цитирования ГоФ

По фотографии диагностируете?

И снова все та же сказка про 3 кита и объекты которые описывают реальный мир.

Никакой связи не вижу.

мутирующие объекты

Если у вас объекты не мутируют, то значит не имеют своего «поведения», потому что поведение будет определятся явной передачей состояния в метод (значит простую функцию) и не может по разному реагировать на сообщения от других объектов (читай, детерминирован). Т.е. у вас остаются values в чистом виде и (возможно) список функций (вполне возможно) с partial application на первый аргумент. И фокус с наследованием здесь уже не пройдет. В чем тогда ООП-шность?

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 04.11.2013 12:52

По фотографии диагностируете?

(судя по вашей фразе)

.

И фокус с наследованием здесь уже не пройдет.

В чем тогда ООП-шность?

Поверх банальной отправки сообщений и протоколов

Відповісти

Підтримати

Alexey Kachayev

Макс Матюхин программист в Badoo 04.11.2013 00:58

учите Haskell, или еще лучше ML

А почему лучше учить ML а не haskell ?

Відповісти

Підтримати

Alexey Kachayev

Ще 4 коментарі

Namdak Tonpa 04.11.2013 05:35

Система типов ML попроще чем в Scala/Haskell, и в будущем станет более понятно место Haskell в мире языков программирования и его уникальных свойств в виде тайпклассов, более мощного лямбда исчисления на типах в виде Kinds Notion, и техники Type Holes Driven Programming, которая предоставляет возможноти полу-автоматической генерации верифицированного кода для таких примитивных алгоритмов как вставка-удаление элементов в B-Tree. Ну и с исторической точки зрения ML — это классика, хотя бы в виде SML/OCaml/F#.

Відповісти

Підтримати

Макс Матюхин

Alexey Kachayev CTO в Attendify 04.11.2013 09:37

Да, совершенно верно.

Відповісти

Підтримати

anonymous 04.11.2013 20:36

-

Відповісти

Підтримати

Макс Матюхин

Alexey Kachayev CTO в Attendify 04.11.2013 21:06

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

Відповісти

Підтримати

anonymous 04.11.2013 21:19

-

undefined pointer 04.11.2013 11:37

Вот есть у вас Еда и Собака.

Это пример овермоделирования. ООП тут ни при чем.

Чтобы дальше рассуждать, про «скормиться» нужно бы вначале ответить на вопросы:
а что такое Еда? а что такое неЕда? а что такое Собака, а что такое неСобака?
то есть — коли взялись творить онтологию — то чтобы не мучиться с неверным выбором — нужно ее и делать как положено. То есть — уходим в немалой сложности философскую задачу.
А если грязно филосфстовать, то и будет дальше демагогия про «скормиться ли должна еда, или накормиться ли должна собака».

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

«Нет никакой ложки!»

Ниже писали про то что ежели DDD воплощать в классах и объектах на ООЯ, то...
и получаем по полной навороченный код, за который и хают ООП — ФПшники.
Но причина не в ООП, а в «овермоделировании»

Відповісти

Підтримати

Alexey Kachayev

Ще 1 коментар

undefined pointer 04.11.2013 12:12

А главное в том, что ООП — это не парадигма, как например процедурное, логическое или функциональное программирование. Вместо этого ООП говорит: «для каждой отдельной задачи вы должны разработать свою собственную парадигму». Другими словами, парадигма объектно-ориентированного проектирования такова: «Программирование — это моделирование».
Oscar Nierstrasz: Десять вещей, которые я терпеть не могу в ООП

В этом и корень проблемы — когда начинают "

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

"

Упущен этап — моделирования. Должно быть: предметная область -> моделирование -> запись модели на ЯП.

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

Відповісти

Підтримати

undefined pointer

anonymous 04.11.2013 17:17

Вот есть у вас Еда и Собака. Может ли Еда скормиться Собаке? Или Собака может Еду съесть? Или нужен Человек, который Собаку накормит Едой? И где хранить информацию о том, что Еда может быть Съедена, а Собака

В чём затруднение? Если речь об открытом игровом мире, то Собака может съесть любой объект у которого есть соответствующий интерфейс и пока свойство IsHungry возвращает true. Если еда на собачьей упряжке (в 1С) то нужен Смок Беллью (bookkeeper role) который будет иметь соответствующий интерфейс для скармливания еды собакам, иначе никто никуда не поедет (non profit organization).

В замечательных, сказочных ФЯ можно скормить собакам не только еду, но и упряжку и самого Беллью, а если покруче завернуть, то и всё белое безмолвие. Только кто потом с этим будет разбираться и искать там баги?

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

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

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

Відповісти

Підтримати

Alexey Kachayev

Ще 12 коментарів

Alexey Kachayev CTO в Attendify 04.11.2013 17:27

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

Это о системе типизации. Совершенно ортогонально обсуждаемому. При этом адекватные системы типизации — как раз таки удел современных ФЯ. (ну если не брать Scala, но и там Java-наследия хватает с ее кастами).

Но как только заказчики приходят из реального мира (Hello, real World!), а не из задачника по математическим олимпиадам, то знание паттернов и ООП резко увеличивает шансы на успешное завершение проекта.

Суровый вброс. Руслан Шевченко писал недавно здесь статью по поводу иллюзионной очевидности мейнстрима. Пишут в реальном мире на ФЯ, нормальные real world проекты (могу это гарантировать личным опытом). Зависимость успешности проекта от применения или не применения ООП никем еще не доказана.

Відповісти

Підтримати

anonymous 04.11.2013 17:34

Если уж о вбросах то ООП это и есть контракт на тип и ничего больше.

Расскажите, пожалуйста про проект на ФЯ для реального мира.

Відповісти

Підтримати

Alexey Kachayev

Namdak Tonpa 04.11.2013 17:51

Не менее 30% всех звонков совершаемых через GSM машрутизаторы обратаываются программами написанными на функциональных или декларативных языках программирования. Остальное в ПЛИС, разработанных с помощью метапрограммирования.

Відповісти

Підтримати

anonymous 04.11.2013 17:55

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

Відповісти

Підтримати

Namdak Tonpa 04.11.2013 18:16

Вот представьте, что вы идете по городу (вы же реальный человек?) и переходите границу зон базовый станций и начинается хендовер и ваш звонок без прекращения разговора нужно перенаправить на другую станцию, а сейчас футбольный матч, а на базовую станцию пришел микроапдейт. Достаточно изменяемый мир? Как нибудь на досуге представьте такую систему написанную с использование паттернов, ООП, SQL и Java. И каждые 3 года новый стандарт: GSM, GPRS, EDGE, UMTS, HSDPA, LTE, 1x, EV-DO, Rev A, B, C, D.

Відповісти

Підтримати

anonymous 04.11.2013 18:23

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

Відповісти

Підтримати

Namdak Tonpa 04.11.2013 18:25

Шаблон Проектирования Шаблон.

Відповісти

Підтримати

anonymous 04.11.2013 18:33

Молодец

Відповісти

Підтримати

Alexey Kachayev CTO в Attendify 04.11.2013 18:21

Предположу, что GSM маршрутизатор, наверное зафиксирован каким-то протоколом лет на десять.

Если бы...

Відповісти

Підтримати

Alexey Kachayev CTO в Attendify 04.11.2013 18:20

Расскажите, пожалуйста про проект на ФЯ для реального мира.

Приходите на Kyiv FProg следующий — как раз буду рассказывать о нашем опыте.

В общем, сочту этот комментарий больше стебом, чем реальной заинтересованность. Так как гуглится без проблем. Посмотрите на компании, пользующиеся Clojure (на вскидку в голову приходит Prismatic, Relevance). По Erlang список получиться тоже не сложно (Amazon, Whatsapp, Heroku, Github, Velti, Echo, Bugsense и др). Погуглите использование Scala / Clojure / Haskell в Twitter / Facebook / Yammer / тд

Відповісти

Підтримати

marko dou 04.11.2013 18:26

окамл janestreet.com/technology еще. вот.

Відповісти

Підтримати

Alexey Kachayev

anonymous 04.11.2013 18:28

Нет никакого стёба.

Відповісти

Підтримати

Alexey Kachayev

Maksym Iemelianov 07.11.2013 20:54

А каким боком Haskell относится к ООП?

Відповісти

Підтримати

Alexey Kachayev

Ще 1 коментар

Alexey Kachayev CTO в Attendify 07.11.2013 21:00

1. смострите мой ответ выше, этот вопрос уже задавали
2. ООП просто частный случай намного более общих вещей
3. dou.ua/calendar/4041

Відповісти

Підтримати

Maksym Iemelianov

Iaroslav Voitovych ¡sí, señor! 14.11.2013 01:53

Вот есть у вас Еда и Собака. Может ли Еда скормиться Собаке? Или Собака может Еду съесть? Или нужен Человек, который Собаку накормит Едой? И где хранить информацию о том, что Еда может быть Съедена, а Собака Накормлена? Чем дальше в лес — тем злее дятлы. Тем толще книги о паттернах. И тем дальше вы от сути ситуации «еда −10, сытость +5».

В МЕМОРИЗ!!!

Відповісти

Підтримати

Alexey Kachayev

Roman Brunets Программист в контрактор 03.11.2013 22:34

Может это все следствия расцвета все тех же 23-летних синьоров? Человек много прочитал, использовать еще не научился, а хочетсо сделать все как взрослые дяди.
Может что-то другое?

Это последствия глупости. Не обращай внимания.

Что на ваш взгляд, является необходимыми навыками/знаниями, чтобы сказать: «Я знаю ООП».

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

Відповісти

Підтримати

Sergius von Bielersee 03.11.2013 22:27

Коментар порушує правила спільноти і видалений модераторами.

Sergey Ponomarev Java & Grails Developer 03.11.2013 22:22

Просто группируешь данные в поля и функции которые работают с этими данными в методы.
Ничего сложного. Остальное оставьте теоретикам.
З.Ы. кстати сегодня проскользнуло в ленте typicalprogrammer.com/...bject-oriented

Відповісти

Підтримати

Євген Остроухов 03.11.2013 22:12

Если человек не пишет так, то он не постиг тайны ООП: github.com/...terpriseEdition

Відповісти

Підтримати

anonymous 03.11.2013 22:12

Декламация GoF на память — так же часть ООП. При том под «знанием паттернов» подразумевают, как правило, не столько умение применять сколько рассказать главу из книги.

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

Лет 5-10 назад знание UML считалось обязательным навыком без которого невозможно знать ООП.

Бо всі наслухались восхвалянь UML на різних конференціях і начитались «розумних книжок». Потім люди, в яких є моск донесли до інших просту істину:

«The dream was that software developers could leave behind the details of textual code and author systems in a higher-level language of diagrams. Indeed, so the dream goes, we might not need programmers at all. Architects could create whole systems from UML diagrams. Engines, vast and cool and unsympathetic to the plight of mere programmers, would transform those diagrams into executable code. Such was the grand dream of Model Driven Architecture (MDA).
Unfortunately, this grand dream has one tiny little flaw. MDA assumes that the problem is code. But code is not the problem. It has never been the problem. The problem is detail.»

Про всі решта модні терміни можна сказати так само, нічого не змінюється, UML, GoF, Stateless design блаблабла, просто з’являються нові базворди, які дійсно вирішують певні проблеми в певних ситуаціях, але їх підносять нам як панацею, як вирішення всіх проблем, і в результаті виходить факап.

tl;dr версія — проблема в тому, що люди люблять кидатись в крайнощі, якщо не кидатись в крайнощі, то і ООП, і SOLID і всі інші підходи по-своєму корисні. ООП має бути без крайнощів, в вашій команді не має бути людей в яких ООП головного моску, але при цьому, всі мають знати що таке S в SOLID і для чого це все придумали

Відповісти

Підтримати

Nikita Podgorbunskyi Software Engineer 04.11.2013 15:59

Как по вашему «що таке S в SOLID»?
просто интересно мнение.

Відповісти

Підтримати

Ще 7 коментарів

anonymous 04.11.2013 19:51

-

Відповісти

Підтримати

Nikita Podgorbunskyi

Kirill Sablin Developer 04.11.2013 20:04

Более глубокое понимание класса и соответственно изменение его названия — это причина?

Відповісти

Підтримати

anonymous 04.11.2013 20:23

-

Відповісти

Підтримати

Kirill Sablin Developer 04.11.2013 20:46

ну вот такой класс

class Manager {
      int action(int a, int b) {
            int result = 0;
            for (int i = 0; i < b; i ++) {
                 result += a;
            }
            return result;
     }
}

Сколько у него ответственностей и причин изменений?
Я клоню к тому, что «одна причина для изменения» — это скорее эвристическое правило, чем определение. И уж точно не тождественна обязанности класса.

Відповісти

Підтримати

anonymous 04.11.2013 21:32

-

anonymous 04.11.2013 21:42

-

anonymous 04.11.2013 21:55

-

anonymous 05.11.2013 12:09

Kirill,

якщо не доколупуватись до термінології і не кидатись штучними прикладами, то визначимо S як «відповідальність за 1 річ (в плані функціоналу)». ІМХО, один з найпростіших і найбільш корисних принципів, розділяєш відповідальності і вийде непогана гнучка модульність. e.g. клас, який пише на файлову систему не серіалізує нічого, для цього є інший сервіс — серіалізатор. І так далі (без фанатизму). Залишим «one reason to change» філософам і теоретикам, нам важливо одне — ми не змішуємо відповідальності, один клас — вирішення однієї задачі

Відповісти

Підтримати

Kirill Sablin Developer 05.11.2013 12:30

Я о том, что не нужно быть категоричным в том что
«one reason to change» === «single responsibility». Оставим категоричность Бобу

Відповісти

Підтримати

anonymous 05.11.2013 13:50

-

anonymous 05.11.2013 15:12

-

anonymous 05.11.2013 15:44

-

anonymous 05.11.2013 15:27

-

anonymous 05.11.2013 15:39

-

anonymous 05.11.2013 15:53

-

anonymous 05.11.2013 16:08

-

Nikita Podgorbunskyi Software Engineer 05.11.2013 10:37

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

Відповісти

Підтримати

anonymous 05.11.2013 10:43

-

anonymous 05.11.2013 12:38

-

anonymous 05.11.2013 12:40

-

Oleh Korotkov девелопер в шоке 03.11.2013 21:44

Что на ваш взгляд, является необходимыми навыками/знаниями, чтобы сказать: «Я знаю ООП».

Ну вот, такое хорошее начало, а тут....

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 03.11.2013 21:52

Ну вот, такое хорошее начало, а тут....

Что тут?
Не нравится формулировка этого вопроса, отвечайте на тот который в заголовке. Можете предложить свою формулировку, возможно включу ее в тему (вроде редактировать пока могу).

Відповісти

Підтримати

Kirill Sablin Developer 03.11.2013 21:00

Как мне видится правильное применение ООП — это со стороны DDD. Т.е. понятия из предметной области моделируются при помощи объектов/сообщений/событий.

Очень многие неверно понимают под ООП использование модулей (попросту сгруппированные функции и данные с возможной инкапсуляцией). Которые, кстати, пришли из ФП:)

btw завтра начинается на курсере реактивное программирование на скала.

Відповісти

Підтримати

Alexey Kachayev CTO в Attendify 03.11.2013 22:58

Где это вы нашли ООП-девелоперов, которые пришли из ФП?

Відповісти

Підтримати

Ще 19 коментарів

Kirill Sablin Developer 04.11.2013 04:13

Модули с инкапсуляцией пришли из ФП, а не девелоперы.

Відповісти

Підтримати

Alexey Kachayev

Ivan Pomidorov 04.11.2013 11:37

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

Відповісти

Підтримати

Kirill Sablin Developer 04.11.2013 11:50

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

Відповісти

Підтримати

Ivan M Software Engineer в Лідер ринку 04.11.2013 20:55

Лисп — не функциональный язык

Відповісти

Підтримати

Kirill Sablin Developer 04.11.2013 20:56

пруф?

Відповісти

Підтримати

Alexey Kachayev CTO в Attendify 04.11.2013 21:12

Помню как-то на fprog в Харькове обсуждался этот вопрос. Тогда сошлись на том, что «функциональный язык это тот язык, который набрался наглости назвать себя функциональным». Есть четкое определение «функционального программирования». Идеально функциональный язык, только lambda calculus в чистом виде. Все практические имплементации — под вопросом.

На сколько я знаю лиспы, то в Common Lisp / Scheme точно есть много не функциональных вещей. Вроде как «самым функциональным» получается Haskell, потому что явное отделение чистого кода от side effects.

Відповісти

Підтримати

Kirill Sablin Developer 04.11.2013 21:35

Ну т.е. проблема лиспа только в том, что в нем есть что-то еще?

Відповісти

Підтримати

Alexey Kachayev

Valeriy Zamaraiev (junior lisper) 09.11.2013 12:47

Более того, то, что в Лиспе полно императивщины — это воспринимается как достоинство, а не недостаток. Кому ФП — берите Хаскель. Ну и ООП (CLOS) очень простой и мощный, и как-то без паттернов живем, точнее может и с неявными паттернами, но так как GoF в данном случае только «scratch the surface», то и не заморачиваемся их формализацией.

Відповісти

Підтримати

Alexey Kachayev

Grez 09.11.2013 13:35

Кому ФП — берите Хаскель.

Хаскель очень полезен для расширения кругозора.
Но у него есть один не достаток — больше он не для чего не нужен.

Відповісти

Підтримати

Valeriy Zamaraiev

Sergii Voloshyn Product Manager в DOU.ua 09.11.2013 15:39

Но у него есть один не достаток — больше он не для чего не нужен.

ЕПАМ, например, постоянно ищет Haskell-разработчиков (или разработчика?):
jobs.dou.ua/...vacancies/8958

Відповісти

Підтримати

Grez

Viacheslav 09.11.2013 18:25

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

Відповісти

Підтримати

Grez

Bogdan Shyiak SE or Dev 09.11.2013 13:47

Ну и ООП (CLOS) очень простой и мощный, и как-то без паттернов живем, точнее может и с неявными паттернами

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

Відповісти

Підтримати

Valeriy Zamaraiev

Ivan M Software Engineer в Лідер ринку 04.11.2013 21:39

А что дает право относить Лисп к ФП? Функции высших порядков? Лямбды? Так это и в С++ есть. Лисп мультипарадигменный, там есть средства и функционального, и объектно-ориентированного, и процедурного, и метапрограммирования.

Відповісти

Підтримати

Kirill Sablin Developer 04.11.2013 21:43

То что он мультипарадигменный, не отнимает у него права отноститься к ФП

Відповісти

Підтримати

Ivan M Software Engineer в Лідер ринку 04.11.2013 21:44

С таким же успехом можно С# отнести туда же.

Відповісти

Підтримати

Kirill Sablin Developer 04.11.2013 21:45

ну в общем-то да

Відповісти

Підтримати

Ivan M Software Engineer в Лідер ринку 04.11.2013 21:46

А Джаву можно? (хочу понять критерий)

Відповісти

Підтримати

Kirill Sablin Developer 04.11.2013 21:52

А по вашему, что можно отнести к функциональным языкам?

Відповісти

Підтримати

Ivan M Software Engineer в Лідер ринку 04.11.2013 23:38

См. пост Алексея выше. Деление весьма условное.
Мой поинт был в другом — «пришло из лиспа» != «пришло из ФП»

Відповісти

Підтримати

Саша Ковалев 09.11.2013 02:42

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

Відповісти

Підтримати

Підписатись на коментарі

Ваша пошта

Не підписуватись