Информация об изменениях

Сообщение Re[16]: Почему программисты прошлого были умнее от 01.02.2026 21:56

Изменено 01.02.2026 21:58 vdimas

Re[16]: Почему программисты прошлого были умнее
Здравствуйте, Sinclair, Вы писали:

V>>Сказал же — нарушение LSP.

S>Ну так его там нет.

О чём и речь.
Полиформизм есть, а соблюдения LSP нет.


V>>Ты его нарушаешь через явный if.

S>Нет.

Вообще-то, именно так LSP и нарушается.


V>>С этим сразу на пересдачу, почему нельзя так делать. ))

S>Кто вам такое сказал?

Накопленные за десятилетия мировые практики.

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

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

И когда я показывал IoC я не называл это единственно работающим решением, я назызывал самым корректным с т.з. безопасности, вот сам этот подход, бо пространство для ошибок сужено почти до 0-ля, в отличие от альтернативных вариантов с if или с ПМ, где полнота ПМ не может быть в общем случае гарантирована системой типов из-за её открытости.

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

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

И в этом красота и универсальность принципа!
Т.е. LSP хорошо работает не только в "чистом ООП", допустим, обжект-паскалевского типа (явовского, C# и т.д.)


V>>Ты давай конкретней, плиз, а то сии эмоции "я очень-очень считаю, что вы очень-очень неправы" — позиция безумца.

S>Конкретно: в примере нет нарушения LSP. Вы его видите — докажите, что оно есть.

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

Ведь задачей LSP является только это — не ветвиться в коде по конкретным типам.
А ведь ты именно это и предлагал — описать null и не-null как различные типы.

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

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

Я спорил лишь с тем, что этот подход в принципе можно считать годным, мы ведь не можем что-то делать на пол-шишечки?
Мы или берём некий "трюк" и признаём его безопасным и подходящим в данной системе ограничений, либо нет.

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

=====
А твои попытки подловить меня на Алголе W, когда ни ты, ни я достоверно не имели на ём достаточной практики (я баловался с каким-то поздним Алголом всего пару раз в жизни) — это и вовсе дно...

Смотри:

V>По ссылке у тебя некая альтернативная реализация Algol W, где прямо указаны отличия от спецификаций Хоара и Вирта.
Да? Процитируйте же эти отличия.

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

Да я-то легко — приводя, к примеру, ссылки на спецификации.

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

Это вообще был один из первых высокоуровневых языков, на котором пытались решать (и достаточно успешно) те задачи, которые раньше решали с помощью ассемблера.
Ну какое в опу GC для системных задач, о чём ты?

А реализацию ты накопал неплохую и она была предназначена для програмирования бизнес-задач.
Да и прекрасно!

Но сама лихорадочная попытка "подловить", и, главное, на чём???
Аааа
Это всё безумие какое-то... нервишки...
В голос, сорри
Re[16]: Почему программисты прошлого были умнее
Здравствуйте, Sinclair, Вы писали:

V>>Сказал же — нарушение LSP.

S>Ну так его там нет.

О чём и речь.
Полиформизм есть, а соблюдения LSP нет.


V>>Ты его нарушаешь через явный if.

S>Нет.

Вообще-то, именно так LSP и нарушается.


V>>С этим сразу на пересдачу, почему нельзя так делать. ))

S>Кто вам такое сказал?

Накопленные за десятилетия мировые практики.

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

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

И когда я показывал IoC я не называл это единственно работающим решением, я назызывал самым корректным с т.з. безопасности, вот сам этот подход, бо пространство для ошибок сужено почти до 0-ля, в отличие от альтернативных вариантов с if или с ПМ, где полнота ПМ не может быть в общем случае гарантирована системой типов из-за её открытости.

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

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

И в этом красота и универсальность принципа!
Т.е. LSP хорошо работает не только в "чистом ООП", допустим, обжект-паскалевского типа (явовского, C# и т.д.)


V>>Ты давай конкретней, плиз, а то сии эмоции "я очень-очень считаю, что вы очень-очень неправы" — позиция безумца.

S>Конкретно: в примере нет нарушения LSP. Вы его видите — докажите, что оно есть.

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

Ведь задачей LSP является только это — не ветвиться в коде по конкретным типам.
А ведь ты именно это и предлагал — описать null и не-null как различные типы.

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

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

Я спорил лишь с тем, что этот подход в принципе можно считать годным, мы ведь не можем что-то делать на пол-шишечки?
Мы или берём некий "трюк" и признаём его безопасным и подходящим в данной системе ограничений, либо нет.

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

=====
А твои попытки подловить меня на Алголе W, когда ни ты, ни я достоверно не имели на ём достаточной практики (я баловался с каким-то поздним Алголом всего пару раз в жизни) — это и вовсе дно...

Смотри:

V>По ссылке у тебя некая альтернативная реализация Algol W, где прямо указаны отличия от спецификаций Хоара и Вирта.
Да? Процитируйте же эти отличия.

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

Да я-то легко — приводя, к примеру, ссылки на спецификации.

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

Это вообще был один из первых высокоуровневых языков, на котором пытались решать (и достаточно успешно) те задачи, которые раньше решали с помощью ассемблера.
Ну какое в опу GC для системных задач, о чём ты?

А реализацию ты накопал неплохую и она была предназначена для програмирования бизнес-задач.
Да и прекрасно!

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