Подходы к разработке ПО и их связь с ООП

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

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

	Комментарий модератора
	Эта тема является выделенной из темы: Записать в файл все слова в верхнем регистре

0

Сообщение от Psilon На уровне ассемблера никаких классов не существует.

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

Сообщение от Psilon а этот бред откуда?

вообще то класс - это структура данных и набор функций для обработки этой структуры - т.е способ группировки функций. Соответсвенно просто следующий шаг развития ФП.

0

Сообщение от Psilon а этот бред откуда?

если бы только этот =) ФП на васике это просто жемчужина.

0

Сообщение от castorsky ФП на васике это просто жемчужина

ФП и на asm возможно и очень широко применялось. просто нужно знать что такое функция и с чем едят. ФП-ники похоже об этом забыли.

0

Fulcrum_013,
группируйте, не группируйте функции... Придумывайте записи или работайте с примитивными данными напрямую...
Это всё будет процедурный подход, методика структурирования кода, но не более.

0

Fulcrum_013, ok, жду currying or pattern matching на выбор с использованием нативных возможностей васика (тоже на выбор).

0

Сообщение от castorsky ok, жду currying or pattern matching на выбор с использованием нативных возможностей васика (тоже на выбор).

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

0

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

0

Сообщение от castorsky Я резонно прошу Вас мне это продемонстрировать.

А че callback на басике никогда не видели - ну дык курите вики и мануалы.

0

Сообщение от Fulcrum_013 А че callback на басике никогда не видели - ну дык курите вики и мануалы.

Понятно. Значит Вы твердо считаете что ФП - это callback. Я правильно понял?

0

Сообщение от castorsky Значит Вы твердо считаете что ФП - это callback. Я правильно понял?

А оно именно этим и является. Вернее именно этим и является лямбда функция. А ФП - это по большому счету набор фобий и святая вера что от всех напастей спасут лямбды и отсутствие переменных.

0

Сообщение от Fulcrum_013 А оно именно этим и является.

Теперь всё понятно. К литературе Вас отсылать конечно бесполезно. Вы, простите, жалок. Даже не стесняетесь говорить то, от чего у любого студента уши в трубочку свернуться. Неужели тяжело просто сказать "Ребят, я не в теме. Я не знаю что это такое, поэтому не могу ничего сказать."? Нет. Вы упорно продолжаете отстаивать свои личные фантазии, проецируя их на реальность. И выдавать эту проекцию за реальность. Пробуждать Вас тоже бесполезно. Это для других, тех кто подумал что Fulcrum_013, что-то вообще понимает в теме беседы: https://en.wikipedia.org/wiki/... rogramming

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

0

Сообщение от castorsky "Ребят, я не в теме. Я не знаю что это такое, поэтому не могу ничего сказать."?

Та нет. Я вобщем то понял что за тема. Просто удивляюсь что до сих пор кто то страдает подобным бредом и боится систем с изменяемыми состояниями.

0

Я не понимаю, о чём вы спорите.

Если о "чистых" концепциях ФП и ООП, то ИМХО некорректно их противопоставлять. Противопоставлять можно декларативные и императивные языки. Функциональный язык может быть одновременно и объектно-ориентированным (и наоборот).
Путь развития императивных языков: Машинные коды. Ассемблер. Языки высокого уровня (COBOL, FORTRAN). Процедурные языки (C, Pascal). Объектно-ориентированные языки (Smalltalk, C++).
И каждый из этих этапов был большим шагом вперёд по сравнению с предыдущим этапом. Поэтому ООП - это, бесспорно, очень полезная концепция.


Если сравнивать декларативные и императивные языки, то (теоретически) первые дают возможность абстрагироваться от реализации и сосредоточиться на предметной области, а вторые, наоборот, дают контроль за порядком вычислений и позволяют писать более производительные программы.
В идеале для написания программы на декларативном языке вообще не нужны никакие знания о программировании. Формулируем набор правил и получаем результат. Но проблема в том, что очень сложно написать для них нормальный компилятор. Чтобы упростить написание компилятора, усложняется язык формулировки правил (насыщается "ненужными" деталями реализации и т.п.). Всплеск интереса к ФЯП в последнее время ИМХО связан с тем, что компьютеры стали гораздо более мощными, а компиляторы - более умными (это позволило получать на выходе машинный код приемлемой производительности).


Если сравнивать конкретные языки программирования, то мы наблюдаем сближение:
В функциональные языки добавляются императивные (мутабельные переменные и т.п.) и ОО черты.
В ОО языки добавляются функциональные черты (лямбды и т.п.)
Начните читать про какой-нибудь современный язык программирования и, скорее всего, увидите что-то типа "этот язык поддерживает несколько парадигм программирования, в том числе структурное, объектно-ориентированное, функциональное и аспектно-ориентированное."

0

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

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

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

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

Добавлено через 2 минуты

Сообщение от Fulcrum_013 Та нет. Я вобщем то понял что за тема. Просто удивляюсь что до сих пор кто то страдает подобным бредом и боится систем с изменяемыми состояниями.

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

0

Сообщение от Psilon а неизменяемым состоянием будущее ибо это единственный нормальный способ писать многопоток без головной боли,

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

0

Сообщение от Psilon просто не в системном программировании

http://mlton.org/References.at... pman02.pdf есть качественный перевод на русский.

0

Сообщение от Psilon а однопоточный код уже лет 15 пытаются замочить, да всё никак

В конечном итоге все прийдет к ситувине один моделируемый объект - один проц. Вот тут ФП и наступят опаньки поскольку взаимодействия между ними (процессами) путем вызовов только будут вносить сумятицу. Останутся именно очереди событий для взаимодействия.

Добавлено через 4 минуты

Сообщение от Psilon автолисп до сих пор как бы в теме

По той же причине что и кобол - под него достаточно много софта. Более свежие чертежные системы используют С++ Api и С-подобные скрипт-языки.

0

Сообщение от Shamil1 Я не понимаю, о чём вы спорите.

Это как бы диалог следующего вида:
- Этот забор красный
- Какая разница? Главное что он твердо стоит на Земле.
- Но ведь он красный?
- Я еще в школе красил заборы разными цветами. И красный тогда пробовал. Главное что он твердо стоит на Земле.

Добавлено через 4 минуты
Psilon, кстати lisp (по умолчанию понимается CL, но и автолисп сюда же) далеко не идиальный кандидат для примера функционального языка. В качестве классических примеров обычно приводят scheme (диалект лиспа) и haskell.

0

Сообщение от Shamil1 В ОО языки добавляются функциональные черты (лямбды и т.п.)

Начнем с того что лямбды фактически есть во всех языках в которых есть возможность использовать indirect call - т.е. в любом импиритивном языке начиная с ASM.

Добавлено через 19 минут

Сообщение от Psilon за неизменяемым состоянием будущее ибо это единственный нормальный способ писать многопоток без головной боли

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

Добавлено через 11 минут

Сообщение от Psilon а неизменяемым состоянием будущее ибо это единственный нормальный способ писать многопоток без головной боли

Многопоток можно тоже по разному использовать. Можно к примеру для суммирования двух векторов запустить кучу потоков каждый из которых просуммирует каждый по одному компоненту вектора, (как это к примеру делается на CUDA), а можно его в одном потоке отдать AVX, который будет по 4 компонента за такт суммировать. Но ни то ни другое не мешает ни операндам ни результату быть полями объекта, а самой функции суммирования векторов быть инкапсулированной в методе. Так же как к примеру при ray-tracing можно каждый луч трассировать в отдельном потоке, при этом как сам луч будет объектом, так и сцена - иерархией объектов, и все будет прекрасно работать.

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

0

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

да ну? Кто бы мог подумать. Только вот 99% задач не в воздухе в вакууме, а планируют какую-то работу сохранять. Всякие там асинхронные серверы, которые кладут в общие потоки заявок запросы, лочат свои потоки при запуске длительной операции, возобновление в том же контексте... Если не нужно, чтобы поток простаивал, нужно как-то возарщать поток в пул, самим ждать колбека, потом восстанавливать стейт руками... Помню, видел пример на плюсах, чуть тошнить не начало.

Сообщение от Fulcrum_013 По той же причине что и кобол - под него достаточно много софта. Более свежие чертежные системы используют С++ Api и С-подобные скрипт-языки.

При чем тут много софта? Я сам писал плагин для автокада, на лиспе было удобнее. При чем тут много софта?

Сообщение от castorsky Psilon, кстати lisp (по умолчанию понимается CL, но и автолисп сюда же) далеко не идиальный кандидат для примера функционального языка. В качестве классических примеров обычно приводят scheme (диалект лиспа) и haskell.

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

0