Forth is so named because in 1968 "the file holding the interpreter was labeled FOURTH, for 4th (next) generation software—but the IBM 1130 operating system restricted file names to 5 characters."[10]
Если вы никогда не писали на низком уровне (машинный код, ассемблер и тд), то это не значит, что ваше высказывание истинно.
Если вы не понимаете определение слова "абстракция" то это не значит что ваше высказывание истинно.
Простой пример: АСУ ТП, когда микроконтроллер имеет только входные данные и управляет исполнительным механизмом — абсолютно никакой абстракции (значение вход, уставка, реакция, управляющий выход и обратная связь).
Простой пример: у некого племени камень лежащий около воды и камень лежащий в лесу обозначались разными словами. А просто слова "камень" не было, и это все абстракции (просто разного уровня). Отсутствие абстракции наверное, это просто взять конкретный камень и начать долбить им конкретный кокос.
А все эти ваши контроллеры, порты, числа, биты — это все абстракции.
Ваш пример абстракции реализации функции enumerate в python — он про абстракцию, но не про разделение кода на куски в цитате которую вы взяли.
А функция это что не один из кусков, на которые разделен код? Пример одновременно про абстракцию и про разбиение на куски. Потому, что это связанные явления — выделение абстракции позволяет отделить код, который занимается обходом коллекции от реализации конкретной коллекции и соответственно выделить обобщенные алгоритмы работы с ними в отдельную библиотеку.
не опровергает или не утверждает разделение кода по различным подключаемым файлам, как средство повышения читабельности кода.
Отвергает, в PHP без ООП вы просто такой функции сделать не сможете и этот кусок у вас буден размазан в разных копиях. Именно больший уровень абстракции позволяет выделять код в разные куски.
В «другой форме» не может, а может только в форме этого языка, то есть в своей форме.
Почему эта форма не может быть названа "другой" по отношению к форме на другом языке?
Простой пример:
Исходная поговорка про скорость вообще ничего не утверждала. При перекодировании внесли ошибку. :D
В контексте обсуждаемой статьи — по сравнению с без ООП.
Судя по уровню вопросов буду считать "Без ООП" для вас это процедурное программирование, а не какие-нибудь монадические комбинаторы.
«Независимость» в ООП — так себе аргумент, особенно при наличии композиции, ассоциации и агрегации. Да и само наследование в ООП подразумевает зависимость дочернего от родительского.
Есть зависимое, есть независимое, абстракции помогают сделать больше частей программы независимыми.
Функции и модули чем не куски? Навскидку, для php, чтобы не было «портянкой» пишите хоть по одной функции в файле и подключайте
Вопрос, что это будут за функции — вот, например функция enumerate в питон. Она приписывает каждому элементу входящей последовательности число по порядку:
И вообще для всего, что можно представить в виде последовательности. Это достигается за счет того, что enumerate работает с абстракцией без знания конкретной реализации — ему надо знать, что исходный список состоит из каких-то элементов, не важно каких и все.
Разве нет разницы между реализации сложной функции лаконичным кодом, а простой функции через «пень-колоду»?
Язык это средство выражения — он может только выразить ту же функциональность в другой форме.
Всегда ли нужна абстракция?
В программировании без абстракции никак. Число — это тоже абстракция. Даже при вождении машины — сейчас можно не знать как именно она работает и пользоваться.
Функции и модули чем не куски?
Функции и модули — это куски просто в ООП больше способов выделить кусок за счет абстрагирования.
Слово "компоненты" я использовал в неформальном значении — как относительно независимый кусок программы.
Взятие интеграла — это функция (и очень сложная), а не сущность.
Почему функция не может быть сущностью?
Пример методов функции на python
> dir(dir)
['__call__', '__class__', '__delattr__', '__dir__', '__doc__', '__eq__','__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__qualname__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__text_signature__']
> dir.__doc__
"dir([object]) -> list of strings\n\nIf called without an argument, return the names in the current scope.\nElse, return an alphabetized list of names comprising (some of) the attributes\nof the given object, and of attributes reachable from it.\nIf the object supplies a method named __dir__, it will be used; otherwise\nthe default dir() logic is used and returns:\n for a module object: the module's attributes.\n for a class object: its attributes, and recursively the attributes\n of its bases.\n for any other object: its attributes, its class's attributes, and\n recursively the attributes of its class's base classes."
>
Какую такую математику надо инжектить в тесты, даже представить не могу.
… и прочитать в сообщении, на которое отвечаете. Кстати еще пример — в конкретном месте поменять реализации на более эффективные для него (типа вычисления через GPU)
В разрезе вопроса о сложности ПО нужно определиться с критерием «сложность» — сложность по реализуемым функциям, данным и т.д., или сложность по исходному коду.
Определите, чем одно отличается от другого
Парадигма ООП позволяет структурировать код ПО и избавиться от дублирования, но не упрощает ни его написание, а в сложных проектах не упрощает и его понимание.
По сравнению с чем? ОО помогает абстрагировать интерфейс от деталей реализации и разбиение на независимые компоненты. Код разбитый на куски понимать легче чем код одним куском.
В современных ОО-языках можно для каждого конкретного случая решать на каком уровне инкапсулировать, есть internal, внутренние классы, дружественные сборки и т.д.
Какие-то подробности реализации можно инкапсулировать на уровне объекта, какие-то на уровне модулей.
А почему "математика" как таковая концептуально не объект? (то, что в java нет в языке хорошего способа описать такие объекты — не аргумент). Я даже могу себе представить инжект разных реализаций математик в разные куски кода (например, в тестовом окружении инжектить какой-нибудь логгирующий декоратор)
Этот пример открывает лишь малую часть зла, ведь инкапсуляция вынуждает делать копии данных, преобразования данных, чтобы не пустить внешний (свой собственный чиорт возьми) код в свои кишки.
В книжках, которые вы читали по предмету объяснялось, зачем нужна инкапсуляция? Вы знаете, что инкапсуляция есть не только в ОО?
Я так понял логику этой статьи, что ERP требует введения регламентов, в который бизнес не укладывается, поэтому, это зло. Т.е. зло — регламенты, а ERP затрудняет их изменение.
Мне было интересно знать, это свойство конкретной ERP, всех ERP или автоматизации как таковой.
Если говорить математически и иммутабельно, то это должно быть что-то вроде
Я говорю не про иммутабельность а про отсутствие мутабельности. Т.е. тип не гарантирует наличие либо отсутствие мутабельности:
interface Rectangle
{
int Height{ get; }
int Width{ get; }
}
Т.е. на прямоугольник вообще не накладывается обязанность, что все его данные где-то хранятся, это может быть динамически вычичляемый по требованию прямоугольник. Или константный прямоугольник 2*1 или прямоугольник для которого хранится размер одной стороны. Или обычный мутабельный прямоугольник который хранит размер двух сторон.
А чем это отличается от создания нового типа? readonly Rect не поддерживает всех операций Rect => это другой тип. Не важно есть у него имя или он конструируется на лету.
Это u было отброшено
Если вы не понимаете определение слова "абстракция" то это не значит что ваше высказывание истинно.
Простой пример: у некого племени камень лежащий около воды и камень лежащий в лесу обозначались разными словами. А просто слова "камень" не было, и это все абстракции (просто разного уровня). Отсутствие абстракции наверное, это просто взять конкретный камень и начать долбить им конкретный кокос.
А все эти ваши контроллеры, порты, числа, биты — это все абстракции.
А функция это что не один из кусков, на которые разделен код? Пример одновременно про абстракцию и про разбиение на куски. Потому, что это связанные явления — выделение абстракции позволяет отделить код, который занимается обходом коллекции от реализации конкретной коллекции и соответственно выделить обобщенные алгоритмы работы с ними в отдельную библиотеку.
Отвергает, в PHP без ООП вы просто такой функции сделать не сможете и этот кусок у вас буден размазан в разных копиях. Именно больший уровень абстракции позволяет выделять код в разные куски.
Почему эта форма не может быть названа "другой" по отношению к форме на другом языке?
Исходная поговорка про скорость вообще ничего не утверждала. При перекодировании внесли ошибку. :D
Ага, понятно. А почему тут принципиальное противоречие с ОО, а не просто ограничения текущей реализации?
Судя по уровню вопросов буду считать "Без ООП" для вас это процедурное программирование, а не какие-нибудь монадические комбинаторы.
Есть зависимое, есть независимое, абстракции помогают сделать больше частей программы независимыми.
Вопрос, что это будут за функции — вот, например функция enumerate в питон. Она приписывает каждому элементу входящей последовательности число по порядку:
И вообще для всего, что можно представить в виде последовательности. Это достигается за счет того, что enumerate работает с абстракцией без знания конкретной реализации — ему надо знать, что исходный список состоит из каких-то элементов, не важно каких и все.
Язык это средство выражения — он может только выразить ту же функциональность в другой форме.
В программировании без абстракции никак. Число — это тоже абстракция. Даже при вождении машины — сейчас можно не знать как именно она работает и пользоваться.
Функции и модули — это куски просто в ООП больше способов выделить кусок за счет абстрагирования.
Слово "компоненты" я использовал в неформальном значении — как относительно независимый кусок программы.
И отлично — это приводит к тому, что программа состоит из кусочков каждый из которых контролирует свою целостность
Почему функция не может быть сущностью?
… и прочитать в сообщении, на которое отвечаете. Кстати еще пример — в конкретном месте поменять реализации на более эффективные для него (типа вычисления через GPU)
А можно на польцах показать, почему невозможен/неудобен интерфейс IMonad?
Это в прошлом (я не знаю сейчас использует кто-то или нет). В настоящем есть javascript где есть такое. Просто ООП больше чем языки с классами.
Определите, чем одно отличается от другого
По сравнению с чем? ОО помогает абстрагировать интерфейс от деталей реализации и разбиение на независимые компоненты. Код разбитый на куски понимать легче чем код одним куском.
В современных ОО-языках можно для каждого конкретного случая решать на каком уровне инкапсулировать, есть internal, внутренние классы, дружественные сборки и т.д.
Какие-то подробности реализации можно инкапсулировать на уровне объекта, какие-то на уровне модулей.
А почему "математика" как таковая концептуально не объект? (то, что в java нет в языке хорошего способа описать такие объекты — не аргумент). Я даже могу себе представить инжект разных реализаций математик в разные куски кода (например, в тестовом окружении инжектить какой-нибудь логгирующий декоратор)
Классы необязательны (см. язык self, например)
В книжках, которые вы читали по предмету объяснялось, зачем нужна инкапсуляция? Вы знаете, что инкапсуляция есть не только в ОО?
Я так понял логику этой статьи, что ERP требует введения регламентов, в который бизнес не укладывается, поэтому, это зло. Т.е. зло — регламенты, а ERP затрудняет их изменение.
Мне было интересно знать, это свойство конкретной ERP, всех ERP или автоматизации как таковой.
Или если я неправильно понял поправьте меня.
Я говорю не про иммутабельность а про отсутствие мутабельности. Т.е. тип не гарантирует наличие либо отсутствие мутабельности:
Т.е. на прямоугольник вообще не накладывается обязанность, что все его данные где-то хранятся, это может быть динамически вычичляемый по требованию прямоугольник. Или константный прямоугольник 2*1 или прямоугольник для которого хранится размер одной стороны. Или обычный мутабельный прямоугольник который хранит размер двух сторон.
Так я писал про создание нового типа, а не про создание нового именованного типа. Анонимные ж типы бывают.
А чем это отличается от создания нового типа? readonly Rect не поддерживает всех операций Rect => это другой тип. Не важно есть у него имя или он конструируется на лету.
Можете проиллюстрировать? Имеется ввиду readonly Rect rect?
биндинга чего к чему?
type guards?