Уважаемый, конкретно твои прогревы просто невозможно смотреть/читать, настолько они унылы.
А уж уровень кринжа - пробивает все рамки:
Когда же вы все свалите из IT, заберете с собой всех ваших "вкатунов", и дадите тем, кому таки интересно программировать, спокойно работать в этой сфере.
Ха-ха, вспомните свои первые "серьезные" программы. Я вот помню - треш был еще тот в форматировании(его отсутствии), нейминге, и т.д.
Рандомный нейминг, сломанное форматирование и т.д. теперь напротив выделает начинающего, который хоть что-то сам пытается делать, а не копипастит код из нейросети, которая всегда делает "минимально приемлемое именование". Т.е. теперь это плюс с позиции оценки преподавателем.
В Paint тоже логика от выкидывания GUI не пострадает? Вы код подобных программ видели вообще? Нет там никакого слоя форм и слоя ядро, вся программа, это единая сущность, все.
Какими еще к черту формами? Я смотрю у бекендеров совсем крыша поехала, везде его видят. Нет. Браузер это просто программа, не фронтенд, не бекенд, обычная, в данном случае десктопная, программа.
Потому что SOLID придумали в первую очередь для ООП. Как и те самые паттерны от банды четырёх.
Тоже на фанат SOLID и обмазывания всего паттернами, но ООП появился до форса этих вещей, и с ними, или без них, отлично выполняет свои задачи. А когда в языке нет ООП, а задача таки требует ООП, приходиться обмазываться костылями, имитирующими ООП.
Проблема не в том, что я не могу сделать что-то без наследования. Проблема в том, что по мере развития языков необходимость в инструментах ООП отпадала, но саму концепцию ООП продолжают продвигать как серебряную пулю
Нет, никуда не отпала необходимость в ООП, а предложение отказа от ООП, чтобы гига-архитекторы не могли что-то настроить безумное - точно такая же серебренная пуля. Они и в языках без ООП настроят бредовых мега абстракций.
Были гига-монолиты на ООП, теперь мега-микросервисы на Go, размазанные по тоннам нод, потому как так принято.
В последствии его идеи были реализованы в языке Simula.
А с чего такая уверенность, что это его идеи были реализованы в языке Simula, а не Smalltalk их взял из Simula?
По годам выходя языков - все равно так, сначала в Simula реализовали ООП, потом Алан Кэй реализовал свое "True ООП" в Smalltalk, и стал рассказывать что все остальное ООП не трушное. Вот только в народ ушло появившееся ранее ООП из Simula.
По статьям все тоже самое:
Самым значительным практическим результатом работы Алана Кэя в Xerox PARC стало создание языка Smalltalk. Существовавшие в то время языки программирования в основном были ориентированы на решение вычислительных задач. Они обладали необходимыми средствами для работы с символами, но были слишком сложны и не соответствовали проекту Dynabook. Поэтому разработке нового языка был отдан высокий приоритет. Некоторые его идеи были заимствованы из Simula и у Пайперта, который создавал язык Logo на основе работ французского психолога Жана Пиаже.
В википедии тоже самое: Smalltalk вдохновлялся Simula, а не наоборот.
Я как раз и говорю, что о понятие ООП размыто до невозможности. Выше мне пишут, что ООП - это только про инкапсуляцию. В таком случае она есть в любом языке.
Верно, все айти термины, абстрактные до невозможности, но в тоже время можно легко сказать что в C нет ООП, а C++ есть, не погружаясь в формализм.
От отсутствия универсального формального определения - ООП он скамом не становиться.
И да, инкапсуляция в том же C заканчивается на "LINKER ERROR: DUPLICATED SYMBOL".
С появлением дженериков возможность абьюзить interface{} практически исчезла
Никуда не исчезла, просто теперь, еще вчера, крутой код стал не желательной практикой.
А нет никакого решения этой выдуманной задачи, так как нет макросов. Такой код просто невозможно написать, а значит и читать его после мега-макрос-хакера не нужно.
Автор же статьи не удосужился показать пример зачем ему это понадобилось. Зато показал как превратить программу в макросный, компилер специфичный, фарш.
Begin
Class Glyph;
Virtual: Procedure print Is Procedure print;;
Begin
End;
Glyph Class Char (c);
Character c;
Begin
Procedure print;
OutChar(c);
End;
Glyph Class Line (elements);
Ref (Glyph) Array elements;
Begin
Procedure print;
Begin
Integer i;
For i:= 1 Step 1 Until UpperBound (elements, 1) Do
elements (i).print;
OutImage;
End;
End;
Ref (Glyph) rg;
Ref (Glyph) Array rgs (1 : 4);
! Main program;
rgs (1):- New Char ('A');
rgs (2):- New Char ('b');
rgs (3):- New Char ('b');
rgs (4):- New Char ('a');
rg:- New Line (rgs);
rg.print;
End;
Живите теперь с этим фактом "скама на первый ООП" от Алана Кея.
Именно - для определенных задач ООП очень удобен, и когда в языке нет ООП, он становиться не очень хорош для определенных классов задач. Автор зачем-то предлагает все ЯП превратить в языки для крудошлепства. А я вот формошлепство люблю - и мне ООП в языке - нужно.
Вы сколько зарабатываете? Ток не на "прогреве", а на самом программировании?
Ооо, еще один прогреваст.
Уважаемый, конкретно твои прогревы просто невозможно смотреть/читать, настолько они унылы.
А уж уровень кринжа - пробивает все рамки:
Когда же вы все свалите из IT, заберете с собой всех ваших "вкатунов", и дадите тем, кому таки интересно программировать, спокойно работать в этой сфере.
Про сам Go только 1 вопрос, остальное про бабки. ~когда же IT очиститься?~
А можно таки не насиловать юзеров терминалом?
Как вообще, спустя 20 лет, после победы GUI, разработчикам обратно продали этот ошметок из 60-х, я даже представить не могу.
Браузер не является честью ОС, можно как снести обычный, так и поставить сторонний.
Частью ОС может быть компонент WebView, как раз умеющий отображать HTML, и не имеющий интерфейса, а в браузере интерфейса достаточно.
Ха-ха, вспомните свои первые "серьезные" программы. Я вот помню - треш был еще тот в форматировании(его отсутствии), нейминге, и т.д.
Рандомный нейминг, сломанное форматирование и т.д. теперь напротив выделает начинающего, который хоть что-то сам пытается делать, а не копипастит код из нейросети, которая всегда делает "минимально приемлемое именование". Т.е. теперь это плюс с позиции оценки преподавателем.
В Paint тоже логика от выкидывания GUI не пострадает? Вы код подобных программ видели вообще? Нет там никакого слоя форм и слоя ядро, вся программа, это единая сущность, все.
Какими еще к черту формами? Я смотрю у бекендеров совсем крыша поехала, везде его видят. Нет. Браузер это просто программа, не фронтенд, не бекенд, обычная, в данном случае десктопная, программа.
Ваш браузер тоже на стороне бекенда?
В мире бекенда так да, но сорян, ваш девайс спроектирован в десктопном приложении.
Когда я изучал ООП, то в книжке был вполне жизненный пример TComponent <- TControl <- TButton, не повезло с книжкой вам, бывает.
А уж в ФП книжках, абстракция на абстракции чаще встречается.
Тоже на фанат SOLID и обмазывания всего паттернами, но ООП появился до форса этих вещей, и с ними, или без них, отлично выполняет свои задачи. А когда в языке нет ООП, а задача таки требует ООП, приходиться обмазываться костылями, имитирующими ООП.
Нет, никуда не отпала необходимость в ООП, а предложение отказа от ООП, чтобы гига-архитекторы не могли что-то настроить безумное - точно такая же серебренная пуля. Они и в языках без ООП настроят бредовых мега абстракций.
Были гига-монолиты на ООП, теперь мега-микросервисы на Go, размазанные по тоннам нод, потому как так принято.
А с чего такая уверенность, что это его идеи были реализованы в языке Simula, а не Smalltalk их взял из Simula?
По годам выходя языков - все равно так, сначала в Simula реализовали ООП, потом Алан Кэй реализовал свое "True ООП" в Smalltalk, и стал рассказывать что все остальное ООП не трушное. Вот только в народ ушло появившееся ранее ООП из Simula.
По статьям все тоже самое:
В википедии тоже самое: Smalltalk вдохновлялся Simula, а не наоборот.
К тому, что теперь идеологи ECS предлагают его использовать для всего подряд, как очередной мега-архитектурный подход, решающий все проблемы.
Верно, все айти термины, абстрактные до невозможности, но в тоже время можно легко сказать что в C нет ООП, а C++ есть, не погружаясь в формализм.
От отсутствия универсального формального определения - ООП он скамом не становиться.
И да, инкапсуляция в том же C заканчивается на "LINKER ERROR: DUPLICATED SYMBOL".
Никуда не исчезла, просто теперь, еще вчера, крутой код стал не желательной практикой.
А тут разве представлен универсальный СИ код? Тут какая-то простыня хаков для конкретных компиляторов, это не СИ код :)
А нет никакого решения этой выдуманной задачи, так как нет макросов. Такой код просто невозможно написать, а значит и читать его после мега-макрос-хакера не нужно.
Автор же статьи не удосужился показать пример зачем ему это понадобилось. Зато показал как превратить программу в макросный, компилер специфичный, фарш.
Кстати, фанатам "того самого ООП в Smalltalk" следует знать, что это не первый ООП язык.
Первый ООП язык, у которого ООП намного более похож на типичный современный ООП, это Simula.
За несколько лет до появления "того самого Smalltalk" в Simula уже были объекты, классы, и наследование.
https://en.wikipedia.org/wiki/Simula
Живите теперь с этим фактом "скама на первый ООП" от Алана Кея.
Именно - для определенных задач ООП очень удобен, и когда в языке нет ООП, он становиться не очень хорош для определенных классов задач. Автор зачем-то предлагает все ЯП превратить в языки для крудошлепства. А я вот формошлепство люблю - и мне ООП в языке - нужно.
Ха, еще один адепт со своей серебряной пулькой прибежал - на этот раз с ECS.
Самое смешное, что на гитхабе наблюдается больше мега-игровых движков с ECS, чем игр на них. Интересно почему.