Сообщение Re[16]: Почему программисты прошлого были умнее от 01.02.2026 21:56
Изменено 01.02.2026 22:05 vdimas
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, когда ни ты, ни я достоверно не имели на ём достаточной практики (я баловался с каким-то поздним Алголом всего пару раз в жизни) — это и вовсе дно...
Смотри:
На память — что-то про строковый тип и еще что-то, цитировать не буду, по твоим ссылкам есть, повторно облом их открывать, бо бессмысленно.
Ведь факт моего процитирования ничего тебе не даст, бо спор принципиальный, то бишь может вестись только о спецификациях языка, а не о подробностях одной из реализаций.
Мне было достаточно указать популярный приём демагогии — на подмену тобой тезиса, где по классике разбивается в пух и прах что-то другое, чем обсуждалось, и значит, "победил!"
Молодец, хорошо порыл интернет и тебе повезло найти реализацию с GC, но точно так же ты найдёшь неоднократное упоминание о том, что в язык преднамеренно не вставляли требования по управлению памяти в спецификацию, т.е. это было сделано специально. Т.е. в том числе этот язык подходил для "встраиваемых" применений уже в те годы, если динамически освобождать память не требовалось.
Это вообще был один из первых высокоуровневых языков, на котором пытались решать (и достаточно успешно) те задачи, которые раньше решали с помощью ассемблера.
Ну какое в опу GC для системных задач, о чём ты?
А реализацию ты накопал неплохую, кстате, и она была предназначена для программирования бизнес-задач.
Да и прекрасно!
Но сама лихорадочная попытка "подловить", и, главное, на чём???
Аааа
Это всё безумие какое-то... нервишки шалят, ы?..
В голос, сорри
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 для системных задач, о чём ты?
А реализацию ты накопал неплохую, кстате, и она была предназначена для программирования бизнес-задач.
Да и прекрасно!
Но сама лихорадочная попытка "подловить", и, главное, на чём???
Аааа
Это всё безумие какое-то... нервишки шалят, ы?..
В голос, сорри
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, когда ни ты, ни я достоверно не имели на ём достаточной практики (я баловался с каким-то поздним Алголом всего пару раз в жизни) — это и вовсе дно...
Смотри:
На память — что-то про строковый тип и еще что-то, цитировать не буду, по твоим ссылкам есть, повторно облом их открывать, бо бессмысленно.
Ведь факт моего процитирования ничего тебе не даст, бо спор принципиальный, то бишь может вестись только о спецификациях языка, а не о подробностях одной из реализаций.
Мне было достаточно указать популярный приём демагогии — на подмену тобой тезиса, где по классике разбивается в пух и прах что-то другое, чем обсуждалось, и значит, "победил!"
Молодец, хорошо порыл интернет и тебе повезло найти реализацию с GC, но точно так же ты найдёшь неоднократное упоминание о том, что в язык преднамеренно не вставляли требования по управлению памяти в спецификацию, т.е. это было сделано специально. Т.е. в том числе этот язык подходил для "встраиваемых" применений уже в те годы, если динамически освобождать память не требовалось.
Это вообще был один из первых высокоуровневых языков, на котором пытались решать (и достаточно успешно) те задачи, которые раньше решали с помощью ассемблера.
Ну какое в опу GC для системных задач, о чём ты?
А реализацию ты накопал неплохую, кстате, и она была предназначена для программирования бизнес-задач.
Да и прекрасно!
Но сама лихорадочная попытка "подловить", и, главное, на чём???
Аааа
Это всё безумие какое-то... нервишки шалят, ы?..
В голос, сорри
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 для системных задач, о чём ты?
А реализацию ты накопал неплохую, кстате, и она была предназначена для программирования бизнес-задач.
Да и прекрасно!
Но сама лихорадочная попытка "подловить", и, главное, на чём???
Аааа
Это всё безумие какое-то... нервишки шалят, ы?..
В голос, сорри