The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

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

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


86. "В состав GCC включена поддержка языка программирования Modul..."  –6 +/–
Сообщение от Аноним (87), 19-Дек-22, 18:09 
Хорошо, я признаю, что C и С++ опасные языки и что они не подходят для написания сколь-нибудь крупных или ответственных приложений. Но на чём тогда писать? На Модуле-2? На Обероне? Или для обычных проектов хватит и Раста? Намного ли Модула-2 лучше чем Раст? Правда интересно, не для холивара...
Ответить | Правка | Наверх | Cообщить модератору

94. "В состав GCC включена поддержка языка программирования Modul..."  +/–
Сообщение от Аноним (97), 19-Дек-22, 18:48 
Зато есть возможность реально всё переписать на Модула-2 потому что под неё прям реально ничего нет.
Ответить | Правка | Наверх | Cообщить модератору

162. "В состав GCC включена поддержка языка программирования Modul..."  +3 +/–
Сообщение от Аноним (38), 19-Дек-22, 22:06 
На Аде пиши. gnat в юниксоподобном вполне юзабелен.
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

175. "В состав GCC включена поддержка языка программирования Modul..."  +/–
Сообщение от iZENemail (ok), 19-Дек-22, 23:05 
> Хорошо, я признаю, что C и С++ опасные языки и что они
> не подходят для написания сколь-нибудь крупных или ответственных приложений. Но на
> чём тогда писать? На Модуле-2? На Обероне? Или для обычных проектов
> хватит и Раста? Намного ли Модула-2 лучше чем Раст? Правда интересно,
> не для холивара...

Eclipse на чём написана?

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

240. "В состав GCC включена поддержка языка программирования Modul..."  +/–
Сообщение от Аноним (237), 20-Дек-22, 08:50 
На ненужноджаве.
Ответить | Правка | Наверх | Cообщить модератору

177. "В состав GCC включена поддержка языка программирования Modul..."  +3 +/–
Сообщение от Аноним (174), 19-Дек-22, 23:10 
> Хорошо, я признаю, что C и С++ опасные языки и что они не подходят для написания сколь-нибудь крупных или ответственных приложений.

Такие приложния давно пишут на Ada и SPARK в частности.

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

219. "В состав GCC включена поддержка языка программирования Modul..."  –3 +/–
Сообщение от Аноним (212), 20-Дек-22, 07:01 
На java
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

257. "В состав GCC включена поддержка языка программирования Modul..."  +4 +/–
Сообщение от Аноним (181), 20-Дек-22, 10:53 
Ага, части Линухового кернела на байткодном языке с виртуальной машиной.
Ответить | Правка | Наверх | Cообщить модератору

319. "В состав GCC включена поддержка языка программирования Modul..."  –2 +/–
Сообщение от Аноним (212), 22-Дек-22, 07:44 
Почему бы нет?
1) Виртуальная машина ebpf в ядре уже есть.
2) java можно скомпилировать через graalvm native-image в исполняемый файл работающий без виртуальной машины

И ты скорее всего не то что модуль ядра, ни одной мало-мальски сложной программы за всю жизнь не написал, а рассуждаешь про "линуховое" ядро

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

230. "В состав GCC включена поддержка языка программирования Modul..."  +7 +/–
Сообщение от Брат Анон (ok), 20-Дек-22, 07:59 
Ты не поверишь: Модула-2 и особенно Оберон предназначены именно для написания больших систем, высоконадёжных приложений и максимальной производительности. Легко переносятся, высокий уровень абстракций, строгая типизация и при сильном желании: ты всё ещё можешь писать низкоуровневый предельно оптимизированный код.


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

288. "В состав GCC включена поддержка языка программирования Modul..."  –2 +/–
Сообщение от warlock66613email (ok), 20-Дек-22, 19:59 
Намного ли Модула-2, созданная во времена, когда компьютерное время было дорогим и главным принципом создания ЯП было максимум работы переложить с компилятора на программиста, лучше чем современный Раст? /ирн

Вообще сравнивать языки из до-ООП эры с языками из пост-ООП эры — такое себе занятие.

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

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
Добавить, Поддержать, Вебмастеру