The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В состав GCC включена поддержка языка программирования Modula-2 , opennews (??), 19-Дек-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


325. "В состав GCC включена поддержка языка программирования Modul..."  +2 +/
Сообщение от Брат Анон (ok), 23-Дек-22, 12:33 
> Намного ли Модула-2, созданная во времена, когда компьютерное время было дорогим и
> главным принципом создания ЯП было максимум работы переложить с компилятора на
> программиста, лучше чем современный Раст? /ирн
> Вообще сравнивать языки из до-ООП эры с языками из пост-ООП эры —
> такое себе занятие.

1) Модула-2 вот ни разу не перекладывает __максимум__ на программиста. Более того, оптимизация алгоритмическая и сейчас лежит на программисте. Машинную оптимизацию Модула не поощряет. Гугли TopSpeed и "Модула-2 Эксельсиор". Эти двое по уровню оптимизации рвут любые компиляторы. Ты что-то путаешь.
2) Модула-2 -- это самый настоящий ООП язык. Тут тебе и встраивание, и сокрытие и полиморфизм (если очень надо, но идеология языка такое не приветствует. Но если надо кушать вообще весь фарш -- есть Модула-3).

Мне очень нравятся подобные ыксперды, которые даже компилятора в глаза не видели и ни одной программы не написали, но своё правильное мнение имеют.

Ответить | Правка | Наверх | Cообщить модератору

326. "В состав GCC включена поддержка языка программирования Modul..."  –1 +/
Сообщение от warlock66613email (ok), 24-Дек-22, 19:01 
Я не говорю про оптимизацию, я говорю про элементарные (как это представляется сегодня) удобства: не писать заголовки процедур дважды (разделение на заголовочную часть и реализацию), не писать объявления переменных заранее отдельно от кода (отдельные блоки var), не писать объявления переменных вообще (автовывод типов), не обязывать программиста соблюдать определённый порядок определения процедур и использовать forward декларации. Язык Modula-2 построен так, чтобы компилятору было удобно с ним работать в ущерб удобству программиста.

Я не говорю, что Модула-2 — это не ООП-язык. Я говорю, что это язык из до-ООП-эры, что вы и подтверждаете, говоря "идеология такое не приветствует". Вирт, безусловно, во многом предвосхитил пост-ООП эру, видя фундаментальные проблемы ООП и отстаивая свою точку зрения, но это больше плюс Вирту, а не плюс его языкам. До сих пор чтобы программисту войти в пост-ООП эру, научиться не использовать ООП, необходимо сначала в совершенстве научиться ООП. Тот же путь было необходимо проделать языкам и отрасли в целом, и Modula-2 — камень из начала этой дороги, а не конца.

Ответить | Правка | Наверх | Cообщить модератору

327. "В состав GCC включена поддержка языка программирования Modul..."  +/
Сообщение от iZENemail (ok), 24-Дек-22, 23:49 
>[оверквотинг удален]
> работать в ущерб удобству программиста.
> Я не говорю, что Модула-2 — это не ООП-язык. Я говорю, что
> это язык из до-ООП-эры, что вы и подтверждаете, говоря "идеология такое
> не приветствует". Вирт, безусловно, во многом предвосхитил пост-ООП эру, видя фундаментальные
> проблемы ООП и отстаивая свою точку зрения, но это больше плюс
> Вирту, а не плюс его языкам. До сих пор чтобы программисту
> войти в пост-ООП эру, научиться не использовать ООП, необходимо сначала в
> совершенстве научиться ООП. Тот же путь было необходимо проделать языкам и
> отрасли в целом, и Modula-2 — камень из начала этой дороги,
> а не конца.

Пост-ООП парадигму программирования вывел Егор Бугаенко, показав всё ничтожество ООП, как программирование со всевозможными нарушениями не только декларируемой инкапсуляции, но и смысла абстрагирования объектов от модели. За это ему честь и хвала!

Ответить | Правка | Наверх | Cообщить модератору

328. "В состав GCC включена поддержка языка программирования Modul..."  +/
Сообщение от warlock66613email (ok), 24-Дек-22, 23:54 
Егор Бугаенко как раз продвигает ООП и критикует современные пост-ООП методы построения архитектуры. Фрик, короче.
Ответить | Правка | Наверх | Cообщить модератору

334. "В состав GCC включена поддержка языка программирования Modul..."  +/
Сообщение от iZENemail (ok), 25-Дек-22, 12:25 
> Егор Бугаенко как раз продвигает ООП и критикует современные пост-ООП методы построения
> архитектуры. Фрик, короче.

Наоборот. Первоначально ООП-программирование реализовывалось как структуры данных и функции (процедуры), объединённых синтаксисом и семантикой ООП-языка. Впервые входящие в ООП не понимали разницы между record (паскалевский термин) и наборами полей классов. Естественно, получались классы-монстры, включающие в себя всевозможный функционал (как, например, первоначальная реализация библиотечного класса Component из Java AWT). Егор критикует подобный подход. Но от этого прикладной код, зависящий от библиотечного и обязанный поддерживать совместимость с тем, что было написано 25 лет назад, никуда не девается.


Ответить | Правка | Наверх | Cообщить модератору

336. "В состав GCC включена поддержка языка программирования Modul..."  +/
Сообщение от warlock66613email (ok), 25-Дек-22, 16:59 
> Егор критикует подобный подход.

Именно. Это очень специфическая точка зрения и она не совпадает с общим направлением в индустрии. Идея пост-ООП в частности и в том, что классы-монстры сами по себе не страшны, так как есть гораздо лучшие способы структурирования кода, пришедшие из функционального программирования, и они ортогональны делению на классы, так что можно иметь отличную архитектуру и хорошо структурированный код в паре классов-монстров. Напротив, подход Егора ведёт к неадекватно большому числу мелких классов с поведением и, зачастую, полиморфных, и в общем превращает код в лапшу.

В общем, Егор говорит "вы делали ООП неправильно (большие классы в частности), давайте делать правильно (маленькие классы)", тогда как правильно так: "ООП плох (неважно в частности большие у вас классы или маленькие), тех же целей можно и нужно достигать принципиально иными средствами".

Некоторые идеи пост-ООП:
- иммутабельность всего и вся (хотя тот же Rust демонстрирует следующую ступень развития этой техники, и позволяет иметь практически все плюсы иммутабельности, сохраняя мутабельность);
- отделение структур данных от алгоритмов и переосмысление инкапсуляции;
- отказ от классического полиморфизма и вообще наследования классов;
- разные техники, идущие из аспектно-ориентированного программирования;
- отказ от неявного состояния и побочных эффектов, весь код в статических методах;
- зачастую отказ от классов вообще, "классы — это замыкания для бедных, а мы богатые".

В общем, это скрытый за фасадом класса-монстра высокоструктурированный код из статических методов, оперируюших маленькими иммутабельными ненаследуемыми классами без инкапсулированного кода (или иногда с минимальным количеством инкапсулированного кода для выражения пары инвариантов), основная инкапсуляция — на уровне модуля, не класса.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру