LINUX.ORG.RU

История изменений

Исправление fsb4000, (текущая версия) :

А вот насчет всяких там ООП, ФП и прочего бреда по части программирования я уверен, что это - мусор. Не только из-за сложности, но и из-за тормознутости и оторванности от реального железа. Учить все более сложные абстракции только чтобы делать все более тормознутый софт - нет, спасибо.

Благодаря абстракциям(в частности ООП) можно развивать задачи огромной сложности на миллионы строк кода.

Всем было пофиг на накладные расходы от ООП даже в 1990 году(выход turbo pascal 6.0) когда это имело какой-то смысл, не говоря уже о 2020.

https://ru.wikipedia.org/wiki/Turbo_Vision

Основным недостатком Turbo Vision можно считать достаточно высокую (для целевой платформы) потребность в оперативной памяти. На типовом для времени выхода библиотеки компьютере с процессором 8086 c 1 Мб ОЗУ под управлением ОС DOS подключение к проекту Turbo Vision часто приводило к необходимости использования оверлейной структуры программы (динамической загрузки кода по частям во время исполнения). Во многом это связано с тем, что в открытой версии, поставлявшейся со средами программирования Borland, библиотеки были написаны на ЯВУ с использованием средств ООП, что само по себе приводило к большому расходу оперативной памяти.

и даже тогда это был топовый выбор для создания tui

Исправление fsb4000, :

А вот насчет всяких там ООП, ФП и прочего бреда по части программирования я уверен, что это - мусор. Не только из-за сложности, но и из-за тормознутости и оторванности от реального железа. Учить все более сложные абстракции только чтобы делать все более тормознутый софт - нет, спасибо.

Благодаря абстракциям(в частности ООП) можно развивать задачи огромной сложности на миллионы строк кода.

Всем было пофиг на накладные расходы от ООП даже в 1990 году(выход turbo pascal 6.0) когда это имело какой-то смысл, не говоря уже о 2020.

https://ru.wikipedia.org/wiki/Turbo_Vision

Основным недостатком Turbo Vision можно считать достаточно высокую (для целевой платформы) потребность в оперативной памяти. На типовом для времени выхода библиотеки компьютере с процессором 8086 c 1 Мб ОЗУ под управлением ОС DOS подключение к проекту Turbo Vision часто приводило к необходимости использования оверлейной структуры программы (динамической загрузки кода по частям во время исполнения). Во многом это связано с тем, что в открытой версии, поставлявшейся со средами программирования Borland, библиотеки были написаны на ЯВУ с использованием средств ООП, что само по себе приводило к большому расходу оперативной памяти.

Исходная версия fsb4000, :

А вот насчет всяких там ООП, ФП и прочего бреда по части программирования я уверен, что это - мусор. Не только из-за сложности, но и из-за тормознутости и оторванности от реального железа. Учить все более сложные абстракции только чтобы делать все более тормознутый софт - нет, спасибо.

Благодаря абстракциям(в частности ООП) можно развивать задачи огромной сложности на миллионы строк кода.

Всем было пофиг на накладные расходы от ООП даже в 1990 году(выход turbo pascal 6.0) когда это имело какой-то смысл, не говоря уже о 2020.

https://ru.wikipedia.org/wiki/Turbo_Vision