А нет никакого решения этой выдуманной задачи, так как нет макросов. Такой код просто невозможно написать, а значит и читать его после мега-макрос-хакера не нужно.
Автор же статьи не удосужился показать пример зачем ему это понадобилось. Зато показал как превратить программу в макросный, компилер специфичный, фарш.
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;
Живите теперь с этим фактом "скама на первый ООП" от Алана Кея.
Именно - для определенных задач ООП очень удобен, и когда в языке нет ООП, он становиться не очень хорош для определенных классов задач. Автор зачем-то предлагает все ЯП превратить в языки для крудошлепства. А я вот формошлепство люблю - и мне ООП в языке - нужно.
Я открыл сорцы компилятора go. И он написан на go.
А когда Go перестал поддерживать некоторые принципы ООП?
Как минимум мы имеем инкапсуляцию(модули), полиморфизм(интерфейсы). (И с каждой версией все больше и больше накручивают, дженерики(параметрический полиморфизм), кастомные итераторы(перезагрузка операторов)).
Или для вас ООП язык - этот тот где нельзя просто процедуры без класса писать? Ну тогда, лол, у вас крайне специфическое понимание ООП. В котором ObjectPascal и C++ - не ООП языки.
Какую серебряную пулю я продаю в статье?
ООП — это скам.
А вот условная java как раз пытается это сделать. Потому что всё есть объект
Нет в джаве не все есть объект, есть примитивные типы аля int.
пиши геттер и сеттер на каждое поле своего класса (даже если тебе это не нужно, а такое бывает часто)
Java не заставляет вас писать сеттер и геттер на каждое поле, это правило хорошего тона, для определенного формата кода, не хотите, не пишите, обращайтесь напрямую.
И да - в Go - все есть interface{} - пихай куда угодно, что угодно, если обсыпал interface{}. Строгость отвалилась, ой. А в джаве кста, не выйдет так.
Java и C# - языки своего времени, где отменили "просто функции", да, это сомнительно по итогу оказалось. Параллельно существуют ObjectPascal и C++, где никто "процедурный подход" не отбирал. Да и новые ЯП процедурный подход разрешают.
В противовес, сейчас, есть новые ЯП насильно впихивающие ФП, Супер-Типы, там где не надо, и отнимающие традиционное ООП, где оно было бы удобно. Все это веяние времени не более, от этого ни ФП, ни ООП, не Типы скамом не становятся.
А еще есть GTK/GNOME, где из-за использования языка без ООП - C, программирование похоже на ад. Причем ад и для самих разрабов GNOME, поэтому, по итогу, они в него js встроили (в виде огромного C++ браузерного движка).
Мир не ограничивается REST ручками и перекладыванием джейсонов, смиритесь. Если вы не осилили другие вещи, и не поняли, зачем нужен ООП, то не ваше это, бывает.
Ок, вот пример "зачем нужно ООП" - сорцы компилятора своего любимого языка открой.
Или покажи действительно хороший, "богатый", десктопный GUI на языках без ООП, где все вынужденны реактивщиной обмазываться, от чего интерфейс "пляшет" от любого чиха, и воспринимается как подделка кривая.
В целом, все ровно так же, как когда-то пихали везде ООП, сейчас пихают Анти-ООП, ФП, ECS, DDD, TDD, MVC, DTO и т.д.
Каждый раз одно и тоже, у очередного автора хорошо что-то вышло на новой, для него, парадигме, и он начинает носиться как угорелый, и пропихивать это везде как серебряную пулю.
Да, да, уважаемый автор статьи, ты точно такой же "заряженный" продаван очередной серебрянной пули, не больше.
Странный вопрос, можно перефразировать "Кому и для чего нужен C#/C/С++/Java/XXX в 25 году, ведь есть JavaScript/Rust/Kotlin/Swift?". Чтобы софт писать вестимо.
Чтобы разобраться в основном языке программирования, который лежит в основе всего, и на котором написано всё остальное - языке программирования Си (он же "Pure C", он же "Си без плюсов") я рекомендую книгу The C Programming Language.
Чего это? Си хайпанул на фоне продвижения UNIX, не более, в основе чего-либо "базового" не был замечен. (Сам UNIX был переписан на Си)
Dolus creates decoys on your PC to discourage malware attacks.
15-20% of malware checks system characteristics before activating. Dolus uses this behavior against them, rendering these threats inert on your PC.
Постыдились бы такое в блоге компании писать, наихудший хак-говнокод, буквально, а они гордятся, лол. Как можно покупать у таких что-то связанное с безопасностью?
Просите, но нет, с позиции обывателя «стоп-кран» - это то, что может дернуть пассажир и почти мгновенно остановить транспортное средство.
Эти же «стоп-краны» доступны только пилотам, и на другой модели самолета могут назваться «подача топлива» или еще как угодно, по другому, и никакого отношения к «стоп-крану», с позиции обычного человека - не имеют.
Это интересный вопрос, и тут можно пошутить! В поезде стоп-кран красного цвета, потому что это срочный сигнал: остановись! Красный всегда ассоциируется с опасностью и требованием немедленного действия. А в самолёте синего цвета, потому что он просто более успокаивающий: когда ты летишь на высоте 10 км, панику разводить не стоит — может, оно и к лучшему, что все чуть-чуть расслаблены!
На самом деле, синий цвет в самолётах используется чаще всего для кнопок обслуживания, таких как вызов стюардессы, а "стоп-кранов" в самолётах нет, так как остановить самолёт в воздухе, к сожалению (или к счастью), невозможно.
Эта H обозначает один байт. Один байт — это 8 битов. 8 битов — это 8 чекбоксов.
А вот и закономерный итог вайтишных курсов, человек поднял целый Redis, но удивляется элементарной кодировке ASCII, при том что это буквально в школьном курсе информатики есть. А мы еще удивлены «детским» взломам, то там, то сям.
UWP, UWP, UWP, они сколько угодно могут переименовывать его в WinUI, WinUI 2, Win UI 3..., но чем больше этого XAML мусора в системе, тем хуже.
Ничего не имею против XAML GPU-First GUI, но это не должно быть базовым системным компонентом.
Все UWP/WinUI - это лагающее убожество, мыльное, с кучей "пустоты", но приправленное "невероятными" анимациями.
И в тоже время, внимания к Win32 GUI все меньше и меньше, даже темную тему не добавили, хотя, для своего "проводника" сделали недокументированный "огрызок" темной темы. Но шутка в том, что все успешные Windows приложения - Win32 based, на который забили.
А тут разве представлен универсальный СИ код? Тут какая-то простыня хаков для конкретных компиляторов, это не СИ код :)
А нет никакого решения этой выдуманной задачи, так как нет макросов. Такой код просто невозможно написать, а значит и читать его после мега-макрос-хакера не нужно.
Автор же статьи не удосужился показать пример зачем ему это понадобилось. Зато показал как превратить программу в макросный, компилер специфичный, фарш.
Кстати, фанатам "того самого ООП в Smalltalk" следует знать, что это не первый ООП язык.
Первый ООП язык, у которого ООП намного более похож на типичный современный ООП, это Simula.
За несколько лет до появления "того самого Smalltalk" в Simula уже были объекты, классы, и наследование.
https://en.wikipedia.org/wiki/Simula
Живите теперь с этим фактом "скама на первый ООП" от Алана Кея.
Именно - для определенных задач ООП очень удобен, и когда в языке нет ООП, он становиться не очень хорош для определенных классов задач. Автор зачем-то предлагает все ЯП превратить в языки для крудошлепства. А я вот формошлепство люблю - и мне ООП в языке - нужно.
Ха, еще один адепт со своей серебряной пулькой прибежал - на этот раз с ECS.
Самое смешное, что на гитхабе наблюдается больше мега-игровых движков с ECS, чем игр на них. Интересно почему.
Это сахар, который может кому-то нравиться, кому-то нет. Но концептуально разницы нет никакой. По факту мы имеем sealed/final классы, все.
А когда Go перестал поддерживать некоторые принципы ООП?
Как минимум мы имеем инкапсуляцию(модули), полиморфизм(интерфейсы). (И с каждой версией все больше и больше накручивают, дженерики(параметрический полиморфизм), кастомные итераторы(перезагрузка операторов)).
Или для вас ООП язык - этот тот где нельзя просто процедуры без класса писать? Ну тогда, лол, у вас крайне специфическое понимание ООП. В котором ObjectPascal и C++ - не ООП языки.
ООП — это скам.
Нет в джаве не все есть объект, есть примитивные типы аля int.
Java не заставляет вас писать сеттер и геттер на каждое поле, это правило хорошего тона, для определенного формата кода, не хотите, не пишите, обращайтесь напрямую.
И да - в Go - все есть interface{} - пихай куда угодно, что угодно, если обсыпал interface{}. Строгость отвалилась, ой. А в джаве кста, не выйдет так.
Java и C# - языки своего времени, где отменили "просто функции", да, это сомнительно по итогу оказалось. Параллельно существуют ObjectPascal и C++, где никто "процедурный подход" не отбирал. Да и новые ЯП процедурный подход разрешают.
В противовес, сейчас, есть новые ЯП насильно впихивающие ФП, Супер-Типы, там где не надо, и отнимающие традиционное ООП, где оно было бы удобно. Все это веяние времени не более, от этого ни ФП, ни ООП, не Типы скамом не становятся.
А еще есть GTK/GNOME, где из-за использования языка без ООП - C, программирование похоже на ад. Причем ад и для самих разрабов GNOME, поэтому, по итогу, они в него js встроили (в виде огромного C++ браузерного движка).
Мир не ограничивается REST ручками и перекладыванием джейсонов, смиритесь. Если вы не осилили другие вещи, и не поняли, зачем нужен ООП, то не ваше это, бывает.
Ок, вот пример "зачем нужно ООП" - сорцы компилятора своего любимого языка открой.
Или покажи действительно хороший, "богатый", десктопный GUI на языках без ООП, где все вынужденны реактивщиной обмазываться, от чего интерфейс "пляшет" от любого чиха, и воспринимается как подделка кривая.
В целом, все ровно так же, как когда-то пихали везде ООП, сейчас пихают Анти-ООП, ФП, ECS, DDD, TDD, MVC, DTO и т.д.
Каждый раз одно и тоже, у очередного автора хорошо что-то вышло на новой, для него, парадигме, и он начинает носиться как угорелый, и пропихивать это везде как серебряную пулю.
Да, да, уважаемый автор статьи, ты точно такой же "заряженный" продаван очередной серебрянной пули, не больше.
Именно поэтому я выбираю Pascal.
А тег КОД уже отменили, или LLM не смогла выдать?
Странный вопрос, можно перефразировать "Кому и для чего нужен C#/C/С++/Java/XXX в 25 году, ведь есть JavaScript/Rust/Kotlin/Swift?". Чтобы софт писать вестимо.
Чего это? Си хайпанул на фоне продвижения UNIX, не более, в основе чего-либо "базового" не был замечен. (Сам UNIX был переписан на Си)
Постыдились бы такое в блоге компании писать, наихудший хак-говнокод, буквально, а они гордятся, лол. Как можно покупать у таких что-то связанное с безопасностью?
Просите, но нет, с позиции обывателя «стоп-кран» - это то, что может дернуть пассажир и почти мгновенно остановить транспортное средство.
Эти же «стоп-краны» доступны только пилотам, и на другой модели самолета могут назваться «подача топлива» или еще как угодно, по другому, и никакого отношения к «стоп-крану», с позиции обычного человека - не имеют.
Это интересный вопрос, и тут можно пошутить! В поезде стоп-кран красного цвета, потому что это срочный сигнал: остановись! Красный всегда ассоциируется с опасностью и требованием немедленного действия. А в самолёте синего цвета, потому что он просто более успокаивающий: когда ты летишь на высоте 10 км, панику разводить не стоит — может, оно и к лучшему, что все чуть-чуть расслаблены!На самом деле, синий цвет в самолётах используется чаще всего для кнопок обслуживания, таких как вызов стюардессы, а "стоп-кранов" в самолётах нет, так как остановить самолёт в воздухе, к сожалению (или к счастью), невозможно.А вот и закономерный итог вайтишных курсов, человек поднял целый Redis, но удивляется элементарной кодировке ASCII, при том что это буквально в школьном курсе информатики есть. А мы еще удивлены «детским» взломам, то там, то сям.
Концепция OpenSource не работает, все сливки по прежнему собирают корпы.
UWP, UWP, UWP, они сколько угодно могут переименовывать его в WinUI, WinUI 2, Win UI 3..., но чем больше этого XAML мусора в системе, тем хуже.
Ничего не имею против XAML GPU-First GUI, но это не должно быть базовым системным компонентом.
Все UWP/WinUI - это лагающее убожество, мыльное, с кучей "пустоты", но приправленное "невероятными" анимациями.
И в тоже время, внимания к Win32 GUI все меньше и меньше, даже темную тему не добавили, хотя, для своего "проводника" сделали недокументированный "огрызок" темной темы. Но шутка в том, что все успешные Windows приложения - Win32 based, на который забили.