Здравствуйте, vsb, Вы писали:
vsb>Главная платформа это веб.
Это для веб-разработчиков.
vsb>Главный современный язык вне веба без легаси это го.
Возьми свой десктоп или смартфон. Сколько там софта на golang?
Это очень сильно нишевой ЯП.
vsb>Второй современный язык вне веба без легаси это раст. ООП там нет.
Еще один модный ЯП.
vsb>Всё ООП в языках из 90-х. Это если ещё не кобол, то близко.
Любой неновый язык можно назвать языком с легаси. А любой язык с легаси — "почти коболом".
Это натягивание совы на глобус, передергивание, перебарщивание, и в любом случае неконструктивно.
Полно традиционных ниш программирования, где все эти гоу и расты — как собаке пятая нога.
ООП работало, конечно, было много копей сломано и лбов расшиблено, но накопился колоссальный опыт того, что полезно, а что — нет.
Re[12]: Кто интересовался, как в 21 веке учить детей програм
Здравствуйте, student__, Вы писали:
__>Здравствуйте, Serginio1, Вы писали: S>> В Паскале тоже не было ООП. Его заменил Delphi
__>стоп! Не знаю, как в оригинальном Паскале, а в ТурбоПаскале ООП появилось в версии 5.5, и было это аж в 1989г., четко до Дельфи.
На ДВК-2 не было. В турбопаскале появился, но не было такого применения как в Делфи в частности в VCL
Главное не возможность, а использование. А вот использование а так же метаклассы ( В VMT с отрицательным смещение хранятся виртуальны "статические" методы класса)
Виртуальные конструкторы https://www.kansoftware.ru/?tid=5048
Кстати появились интерфейсы для работы с COM.
и солнце б утром не вставало, когда бы не было меня
__>Однобокая трактовка программирования. Программирование уже давно не только занятие инженеров в области вычислительной техники. __>Может быть, это сложно представить человеку с профильным инженерно-компютерным образованием, но многим людям, которые применяют программирование, вовсе не нужно знать, что есть какие-то там регистры, и как машинерия устроена под условным капотом. И это знание, получи они его, не сделает их код ни на копейку лучше.
С одной стороны так, а с другой как только у нас есть многопоточность, то тут же возникают всякие volatile, interlocked и прочие "memory barriers", а за ними кэши и ядра.
(из последних обсуждений: Memory barrier не могу понять что это)
Re[10]: Кто интересовался, как в 21 веке учить детей программ
Здравствуйте, student__, Вы писали:
vsb>>Главная платформа это веб. __>Это для веб-разработчиков.
Веб уже давно везде, где UI.
vsb>>Главный современный язык вне веба без легаси это го. __>Возьми свой десктоп или смартфон. Сколько там софта на golang?
На смартфоне софт на JS. За редким исключением.
__>Полно традиционных ниш программирования, где все эти гоу и расты — как собаке пятая нога.
Полно. Но полно также и ниш, где ООП нет.
Я не предлагаю отказываться от ООП. Понятно, что если мне взбредёт в голову писать для iOS на Swift, то я буду вынужден использовать классы (хотя SwiftUI мне показался не ООП-ориентированным, но я его мельком видел). Я говорю про то, что всем ООП изучать может быть и не нужно. Так же, как всем не нужно изучать ORM. Это нишевые технологии. Вот SQL изучить всем полезно.
Re[11]: Кто интересовался, как в 21 веке учить детей программ
Здравствуйте, vsb, Вы писали:
vsb>Веб уже давно везде, где UI.
У меня UI на Qt.
vsb>На смартфоне софт на JS. За редким исключением.
Android: Kotlin, Java. iOS: Swift.
vsb>Полно. Но полно также и ниш, где ООП нет.
это не значит, что ООП — антипаттерн
vsb>Я не предлагаю отказываться от ООП
но твоё "ООП — антипаттерн" звучит именно так
Re[14]: Кто интересовался, как в 21 веке учить детей програм
Здравствуйте, Serginio1, Вы писали:
S> __>стоп! Не знаю, как в оригинальном Паскале, а в ТурбоПаскале ООП появилось в версии 5.5, и было это аж в 1989г., четко до Дельфи.
S> На ДВК-2 не было. В турбопаскале появился, но не было такого применения как в Делфи в частности в VCL
Ну да... А TurboVision на которой строились все борландовские IDE?
S>> __>стоп! Не знаю, как в оригинальном Паскале, а в ТурбоПаскале ООП появилось в версии 5.5, и было это аж в 1989г., четко до Дельфи.
S>> На ДВК-2 не было. В турбопаскале появился, но не было такого применения как в Делфи в частности в VCL
R>Ну да... А TurboVision на которой строились все борландовские IDE?
Ну давай сравним с VCL по количеству компонентов? https://ru.wikipedia.org/wiki/Turbo_Vision
Основным недостатком Turbo Vision можно считать достаточно высокую (для целевой платформы) потребность в оперативной памяти. На типовом для времени выхода библиотеки компьютере с процессором 8086 c 1 Мб ОЗУ под управлением ОС DOS подключение к проекту Turbo Vision часто приводило к необходимости использования оверлейной структуры программы (динамической загрузки кода по частям во время исполнения). Во многом это связано с тем, что в открытой версии, поставлявшейся со средами программирования Borland, библиотеки были написаны с использованием средств ООП, что само по себе приводило к большому расходу оперативной памяти. При этом в самой Borland IDE, по утверждениям исследовавших код хакеров, использовался ассемблерно-оптимизированный вариант, гораздо более экономный по объёму кода и затратам памяти.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> R>Ну да... А TurboVision на которой строились все борландовские IDE?
S> Ну давай сравним с VCL по количеству компонентов?
Ага, давайте сравним текстовый гуй с графическим...
S> https://ru.wikipedia.org/wiki/Turbo_Vision
S> Основным недостатком Turbo Vision можно считать достаточно высокую (для целевой платформы) потребность в оперативной памяти. На типовом для времени выхода библиотеки компьютере с процессором 8086 c 1 Мб ОЗУ под управлением ОС DOS подключение к проекту Turbo Vision часто приводило к необходимости использования оверлейной структуры программы (динамической загрузки кода по частям во время исполнения). Во многом это связано с тем, что в открытой версии, поставлявшейся со средами программирования Borland, библиотеки были написаны с использованием средств ООП, что само по себе приводило к большому расходу оперативной памяти. При этом в самой Borland IDE, по утверждениям исследовавших код хакеров, использовался ассемблерно-оптимизированный вариант, гораздо более экономный по объёму кода и затратам памяти.
Что ты этим хочешь сказать? Что ООП в TV небыло? Или что? В отличи от исследовавших код хакеров, мы писали с использованием TV, а после и с одним из ее графических вариантов. И работало все без оверлеев. Не помню, использовались ли оверлеи в доснавигаторе, который тоже был написан с использованием TV. Оверлеи, кстати, в те времена использовались вообще достаточно щироко вне зависимости от TV. Например, была такая среда программирования и одноименный язык Clipper, там без оверлеев вообще было сложно что-либо делать т.к. памяти оно жрало, как не в себя, и безо всякого ООП.
Здравствуйте, rudzuk, Вы писали:
S>> https://ru.wikipedia.org/wiki/Turbo_Vision
S>> Основным недостатком Turbo Vision можно считать достаточно высокую (для целевой платформы) потребность в оперативной памяти. На типовом для времени выхода библиотеки компьютере с процессором 8086 c 1 Мб ОЗУ под управлением ОС DOS подключение к проекту Turbo Vision часто приводило к необходимости использования оверлейной структуры программы (динамической загрузки кода по частям во время исполнения). Во многом это связано с тем, что в открытой версии, поставлявшейся со средами программирования Borland, библиотеки были написаны с использованием средств ООП, что само по себе приводило к большому расходу оперативной памяти. При этом в самой Borland IDE, по утверждениям исследовавших код хакеров, использовался ассемблерно-оптимизированный вариант, гораздо более экономный по объёму кода и затратам памяти.
R>Что ты этим хочешь сказать? Что ООП в TV небыло? Или что? В отличи от исследовавших код хакеров, мы писали с использованием TV, а после и с одним из ее графических вариантов. И работало все без оверлеев. Не помню, использовались ли оверлеи в доснавигаторе, который тоже был написан с использованием TV. Оверлеи, кстати, в те времена использовались вообще достаточно щироко вне зависимости от TV. Например, была такая среда программирования и одноименный язык Clipper, там без оверлеев вообще было сложно что-либо делать т.к. памяти оно жрало, как не в себя, и безо всякого ООП.
Я хочу сказать, что хоть оно и было, но для 1 Мб ОЗУ все таки ООП было накладно для больших программ.
ООП как раз и расцвело когда можно было создавать сложные программы с использованием бОльших ресурсов.
и солнце б утром не вставало, когда бы не было меня
Re[18]: Кто интересовался, как в 21 веке учить детей програм
Здравствуйте, Serginio1, Вы писали:
S> Я хочу сказать, что хоть оно и было, но для 1 Мб ОЗУ все таки ООП было накладно для больших программ.
Это чушь невероятная. В объекте из служебных данных всего одна ссылка на vmt, а vmt это статичная таблица специфичная для каждого класса. У борландов даже в vmt место экономилось при использовании динамических методов вместо виртуальных, ценой более сложного резолвинга. Я к тому, что поиметь проблем памятью из-за использования ООП можно было только в том случае, если проповедовать жабью идеологию все-объект. В паскале, к счастью, эту шизу не словили.
Я помню из-за чего у нас были проблемы с памятью — из-за баз данных и графического гуя, но не из-за ООП.
S> ООП как раз и расцвело когда можно было создавать сложные программы с использованием бОльших ресурсов.
ООП расцвело, когда его стали поддерживать языки. Очень удобная штука, оказалось, если головой об угол не прикладываться.
Здравствуйте, Serginio1, Вы писали:
S>Я хочу сказать, что хоть оно и было, но для 1 Мб ОЗУ все таки ООП было накладно для больших программ. S>ООП как раз и расцвело когда можно было создавать сложные программы с использованием бОльших ресурсов.
Дело не в ООП, а в том, что для чего-то сложного 1 Мб ОЗУ (фактически 640 Кб минус резидентные проги и DOS, т.е. 500 Кб с чем-то, а всякие EMS и XMS через одно место требовалось программировать) было очень мало. С ООП или без него, но приличный GUI требовал большого расхода памяти. И оверлеи тогда использовали практически все сколько-то серьезные программы.
Re[2]: Кто интересовался, как в 21 веке учить детей программированию?
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Подход давным давно имеет место быть. Lego Mindstorms NXT с усечённой детско-юношеской версией графического языка программирования LabVIEW появился, емнип, в 2006-м.
Интересно, а есть программисты, которые могут сказать, что они когда-то начинали с Lego или чего-то подобного?
Re[19]: Кто интересовался, как в 21 веке учить детей програм
Здравствуйте, Michael7, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>>Я хочу сказать, что хоть оно и было, но для 1 Мб ОЗУ все таки ООП было накладно для больших программ. S>>ООП как раз и расцвело когда можно было создавать сложные программы с использованием бОльших ресурсов.
M>Дело не в ООП, а в том, что для чего-то сложного 1 Мб ОЗУ (фактически 640 Кб минус резидентные проги и DOS, т.е. 500 Кб с чем-то, а всякие EMS и XMS через одно место требовалось программировать) было очень мало. С ООП или без него, но приличный GUI требовал большого расхода памяти. И оверлеи тогда использовали практически все сколько-то серьезные программы.
Ну я про то и говорю. ООП это прежде всего про сложную архитектуру и соответственно сложность программ. DOS это ограничивал. Все старались использовать память по минимуму.
Кстати в Delphi тоже были объекты на стеке (типа record но с vmt)
и солнце б утром не вставало, когда бы не было меня
Re[20]: Кто интересовался, как в 21 веке учить детей програм
Здравствуйте, Serginio1, Вы писали:
S> Ну я про то и говорю. ООП это прежде всего про сложную архитектуру и соответственно сложность программ. DOS это ограничивал. Все старались использовать память по минимуму.
ООП это прежде всего про инкапсуляцию, полиморфизм и наследование. Использование ООП совсем не подразумевает наличия развесистых абстракций и не проповедует сложность. А памяти было мало, да, хоть с ООП хоть без оного.
S> Кстати в Delphi тоже были объекты на стеке (типа record но с vmt)
Что значит были? Они есть и сейчас, только давным-давно объявлены легаси, что, впрочем, не мешает их использовать.
Здравствуйте, rudzuk, Вы писали:
R>Я помню из-за чего у нас были проблемы с памятью — из-за баз данных и графического гуя, но не из-за ООП.
S>> ООП как раз и расцвело когда можно было создавать сложные программы с использованием бОльших ресурсов.
R>ООП расцвело, когда его стали поддерживать языки. Очень удобная штука, оказалось, если головой об угол не прикладываться.
Проблема ООП это прежде всего память в куче. Кстати в Delphi помню тоже были какие то структуры на стеке с VMT.
А вот менеджер памяти как раз и сжирает огромные количества памяти в отличие от стека.
Я к тому, что каждому овощу свое время. Как только появился Windows 95 выполнять 32-разрядные приложения на основе API Win32 то появились и сложные программы, где уже для упрощения написания кода уже понадобился ООП. Кроме того и среда разработки и отладки резко улучшились.
и солнце б утром не вставало, когда бы не было меня
Re[20]: Кто интересовался, как в 21 веке учить детей програм
Здравствуйте, Serginio1, Вы писали:
S> Проблема ООП это прежде всего память в куче. Кстати в Delphi помню тоже были какие то структуры на стеке с VMT. S> А вот менеджер памяти как раз и сжирает огромные количества памяти в отличие от стека.
Любой, сколь нибудь сложный, софт, это про динамическую память.
S>> Ну я про то и говорю. ООП это прежде всего про сложную архитектуру и соответственно сложность программ. DOS это ограничивал. Все старались использовать память по минимуму.
R>ООП это прежде всего про инкапсуляцию, полиморфизм и наследование. Использование ООП совсем не подразумевает наличия развесистых абстракций и не проповедует сложность. А памяти было мало, да, хоть с ООП хоть без оного.
Но как раз их использовать проще когда она развесистая как в VCL. В итоге все упиралось в память.
А основная фишка Delphi это как раз менеджер памяти https://www.rsdn.org/article/Delphi/memmanager.xml
S>> Кстати в Delphi тоже были объекты на стеке (типа record но с vmt)
R>Что значит были? Они есть и сейчас, только давным-давно объявлены легаси, что, впрочем, не мешает их использовать.
Напомни как назывались. А то забыл совсем. Закинул Delphi уже лет 15. Но до сих пор его люблю
и солнце б утром не вставало, когда бы не было меня
