Модульные системы программирования
От: varenikAA  
Дата: 08.07.20 01:15
Оценка: +1 -2 :))) :))) :))) :)
Наткнулся на описание Oberon (система Black Box).
https://oberoncore.ru/library/gubanov_sekrety_modulnyh_sistem
Внезапно осознал, что мало какие ЯП являются модульными.
И еще поразило, вот это:

Ведь .Net система больше похожа на монотонно растущую монолитную программу, чем на динамически расширяемую модульную систему. Для удобства программирования «на больших масштабах» предлагается использовать не средства языка, а вспомогательные инструменты интегрированной среды разработки.


Уже второй раз нахожу подобную мысль.
Уолтер Брайт:

Один мой коллега с богатым производственным опытом заметил,
что IDE – необходимый для программирования инструмент,
потому что позволяет одним щелчком мыши сгенерировать сотни строк стандартного кода.
При использовании языка D нет острой потребности в IDE, поскольку,
вместо того чтобы полагаться на фокусы генерации «заготовок» разного рода
«помощниками», D исключает саму идею стандартных заготовок, применяя
интроспекцию и собственные возможности генерации кода.
Программист уже не увидит стандартный код.
О присущей программам сложности заботится язык, а не IDE.


Даже удивительно, что в 2020 UI (Black Box) занимает 500K ОЗУ.
Полез в ютуб — оказалось в РФ очень активно его используют для прошивки железа, но и для современных задач(типа рисования в html5).

Т.е. по сути весь огород с версиями сборок в .net оказался фикцией, разбивка на модули сделана лишь частично.
В настоящее время основной подход — монолит. Разделение интерфейсов только на уровне кода.

PS можно считать динамические языки типа common lisp, clojure модульными?
PS PS можно считать скриптовый режим F# модульным:
#load script-v1.fsx?
#load script-v2.fsx?
☭ ✊ В мире нет ничего, кроме движущейся материи.
Отредактировано 08.07.2020 1:18 Разраб . Предыдущая версия .
Re: Модульные системы программирования
От: ole! США http://files.rsdn.org/4543/rsdn.gif
Дата: 08.07.20 01:20
Оценка: +3 -2
Здравствуйте, varenikAA, Вы писали:

AA>Наткнулся на описание Oberon (система Black Box).

AA>https://oberoncore.ru/library/gubanov_sekrety_modulnyh_sistem
AA>Внезапно осознал, что мало какие ЯП являются модульными.
AA>И еще поразило, вот это:

синтаксический оверхед детектед!
Sergey Gubanov, перелогинтесь!
my $.02
Re: Модульные системы программирования
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 08.07.20 01:38
Оценка:
Здравствуйте, varenikAA, Вы писали:

AA>«помощниками», D исключает саму идею стандартных заготовок, применяя

AA>интроспекцию и собственные возможности генерации кода.
AA>Программист уже не увидит стандартный код.
AA>О присущей программам сложности заботится язык, а не IDE.

Да вроде D такой же язык как и все остальные, чего там особенного-то? Я предполагаю, что автор этого высказывания просто знает D очень и очень хорошо, и поэтому ему не нужен IDE. IDE — это утилита которая позволяет писать код на (мало/недостаточно)знакомом языке так, будто ты его хорошо знаешь.
Re: Модульные системы программирования
От: ole! США http://files.rsdn.org/4543/rsdn.gif
Дата: 08.07.20 01:49
Оценка: +2
Здравствуйте, varenikAA, Вы писали:

AA>Уже второй раз нахожу подобную мысль.

AA>Уолтер Брайт:
AA>

AA>Один мой коллега с богатым производственным опытом заметил,
AA>что IDE – необходимый для программирования инструмент,
AA>потому что позволяет одним щелчком мыши сгенерировать сотни строк стандартного кода.
AA>При использовании языка D нет острой потребности в IDE, поскольку,
AA>вместо того чтобы полагаться на фокусы генерации «заготовок» разного рода
AA>«помощниками», D исключает саму идею стандартных заготовок, применяя
AA>интроспекцию и собственные возможности генерации кода.
AA>Программист уже не увидит стандартный код.
AA>О присущей программам сложности заботится язык, а не IDE.


И вот интересно, на самом деле. Чем Уолтер Брайт пользуется для работы с кодом? В большом объеме кода, 100500 KLOC? В чём зло IDE?

Обычно IDE используется не столько для генерации кода, как для быстрой семантической навигации по большому проекту, не обязательно состоящему из сгенерированного кода. Например в Java можно даже и не увидеть сгенерированного кода за ненадобностью, и увидеть, если надо настроить под свои специфические нужды (xjc, etc.).
IDE удобно использовать для рефакторинга кода (не на уровне текста, а на семантическом уровне, AST, ..). Для контекстного автодополнения во время написания кода. Для интерактивной отладки и статического анализа кода. Для удобства быстрой работы со множеством файлов, классов, компонент, библиотек и т.п. Для быстрой сборки больших проектов. Для удобной работы с Git. Для автоматизации разных вещей. Тупо для проверки и соблюдения стиля кодирования и правописания.

Наблюдаю за любителями делать IDE из Vim и Emacs и думаю, что ж вы, ребята, так себя ненавидете?

Берем теперь D. Или скалу какую-нибудь, и проект написанный до вас, в очень продуктивной и дружной команде фанатов DSL и хитрых языков, которые "... применяют интроспекцию и собственные возможности генерации кода. Программист уже не увидит стандартный код. " Скорее, увидит пустой экран и/или нестандартный код. Хорошо, если он работает как надо, и полный облом, если нет. Что там происходит, если всё по конвенции, все подразумевается, а вы не знаете этих конвенций или их задолго до вас приняли, а рассказать забыли?
my $.02
Re[2]: Модульные системы программирования
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 08.07.20 01:55
Оценка: :))
Здравствуйте, ole!, Вы писали:

O>И вот интересно, на самом деле. Чем Уолтер Брайт пользуется для работы с кодом? В большом объеме кода, 100500 KLOC? В чём зло IDE?


Они часто тормозят и перегружают информацией.

O>Наблюдаю за любителями делать IDE из Vim и Emacs и думаю, что ж вы, ребята, так себя ненавидете?


Отчасти ты, конечно прав, но тут есть нюансы. Vim/Emacs позволяют получить именно то, что хочется, а не то, что решил нужным производитель IDE. Долгое время им реально не было альтернатив, особенно короссплатформенных. В последние годы JetBrains наконец-то смогли сделать практически идеальные IDE для всех языков кроме разве что C++, где Vim/Emacs до сих пор могут предложить больше или хотя бы не тормозить люто
Re[3]: Модульные системы программирования
От: ole! США http://files.rsdn.org/4543/rsdn.gif
Дата: 08.07.20 02:18
Оценка:
Здравствуйте, kaa.python, Вы писали:




KP>Отчасти ты, конечно прав, но тут есть нюансы. Vim/Emacs позволяют получить именно то, что хочется, а не то, что решил нужным производитель IDE. Долгое время им реально не было альтернатив, особенно короссплатформенных. В последние годы JetBrains наконец-то смогли сделать практически идеальные IDE для всех языков кроме разве что C++, где Vim/Emacs до сих пор могут предложить больше или хотя бы не тормозить люто


JetBrains молодцы, на самом деле, общался с командой Clion на CppCon 2018-2019. Очень нетривиально сделать для С++ IDE на уровне, как они сделали для Java, Python, Golang, Ruby, JS и С#, отзывчивую IDE, работающую с тысячами файлов. У них очень интересные сессии на CppCon про С++ с упором на IDE, парсинг, и рефакторинг. Вообще, интересная компания и толковые ребята. Сам пользуюсь CLion и vscode.

>Vim/Emacs до сих пор могут предложить больше


да, но это не Vim/Emacs, а LSP и clangd. И vscode там же. И, что интересно, CLion тоже использует clangd для всего этого, из коробки, как дополнение к собственным парсерам JetBrains. От LSP и clangd выигрывают все, много кто над этим работает и все это open source.
См CppCon 2018: Ilya Biryukov “Clangd: architecture of a scalable C++ language server"
Илья перебрался из JetBrains в Google, неспроста.
my $.02
Отредактировано 08.07.2020 2:18 .... . Предыдущая версия .
Re[4]: Модульные системы программирования
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 08.07.20 02:44
Оценка: +1
Здравствуйте, ole!, Вы писали:

O>JetBrains молодцы, на самом деле, общался с командой Clion на CppCon 2018-2019. Очень нетривиально сделать для С++ IDE на уровне, как они сделали для Java, Python, Golang, Ruby, JS и С#, отзывчивую IDE, работающую с тысячами файлов.


Я бы сказал CLion мало для чего кроме очередного Hello World подходит, так как, с одной стороны, ни с чем кроме CMake не умеет работать (ага, в мире C++, где десятки разных систем сборки ), и при этом дико тормозит особенно на проектах с шаблонами.
Re[5]: Модульные системы программирования
От: LaptevVV Россия  
Дата: 08.07.20 04:28
Оценка:
Поддерживаю!
KP>Я бы сказал CLion мало для чего кроме очередного Hello World подходит, так как, с одной стороны, ни с чем кроме CMake не умеет работать (ага, в мире C++, где десятки разных систем сборки ), и при этом дико тормозит особенно на проектах с шаблонами.
Я у себя в Астраханском и сам попробовал, и пацанам сказал — давайте в CLion.
Попробовали многие. Некоторые очень продвинутые.
Бросили все.
По причине тормознутости.
На удивление Rider у них — великолепная система.
Некоторые пацаны сейчас работают, а я попробовал еще предрелиз.
ВСЕ хвалят, кто работает.
Видимо, по сравнению со Студией — маленькая, делает все.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Модульные системы программирования
От: LaptevVV Россия  
Дата: 08.07.20 04:30
Оценка:
Модули в Си-подобных языках отсутствуют как в принципе!
Вот сейчас в С++20 что-то сделали, но очень странное.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: Модульные системы программирования
От: ole! США http://files.rsdn.org/4543/rsdn.gif
Дата: 08.07.20 04:46
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Я бы сказал CLion мало для чего кроме очередного Hello World подходит, так как, с одной стороны, ни с чем кроме CMake не умеет работать (ага, в мире C++, где десятки разных систем сборки ), и при этом дико тормозит особенно на проектах с шаблонами.


Замечательно работает у меня и в команде с мака и дебиан линукса (или с RHEL 7). Не сказал бы что пишем код мелкого размера, у нас есть всё, и буст, и свой кросс платформенный фреймворк с полиморфными аллокаторами под big iron (Solaris, AIX), Linux и Windows, заточенный на работу в финансах и low latency/low overhead. Сериализация и метаданные классов DTO/VST для ORM с помощью type traits и рекурсивных шаблонов — все это инлайнится по надобности для производительности и кэш локальности. Много кода и легаси С с классами и посовременней C++14 и С++ 17. Даже фортран есть, кому надо, через плагин.

Практика показала что CMake с Ninja build замечательно работает с этими большими проектами, по сравнению с рекурсивными make скриптами, в разы, ну и compile_commands.json хорошо идет в придачу. В новом CLion 2020.2 EAP добавили уже Make проекты, кстати, но кому он нужен, когда есть CMake. Они тупо парсят выхлоп make и вытаскивают опции для препроцессора, компилятора и линкера (или просто прокси процесс как фронтенд тулчейна построенного на gcc/llvm). Мы просто сконвертили все что нужно в CMake (тулчейнов много разных у нас всяких и хитрые опции билда). Есть Bazel plugin от Google, с этим не работал.

Добавить 2 GB в CLion vmoptions.props и работа с SSD — это просто минимум сегодня. Ну и удаленные билды на билд кластере и докер клауд параллельно для кросс платформы и тулчейнов + 40 cores и 1 TB RAM ноды

Когда это не помогает с 50kloc — просто выключаешь в Clion инспектора внизу в статус баре и нормально дальше работаешь.
my $.02
Re[6]: Модульные системы программирования
От: ole! США http://files.rsdn.org/4543/rsdn.gif
Дата: 08.07.20 05:06
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Поддерживаю!

KP>>Я бы сказал CLion мало для чего кроме очередного Hello World подходит, так как, с одной стороны, ни с чем кроме CMake не умеет работать (ага, в мире C++, где десятки разных систем сборки ), и при этом дико тормозит особенно на проектах с шаблонами.
LVV>Я у себя в Астраханском и сам попробовал, и пацанам сказал — давайте в CLion.
LVV>Попробовали многие. Некоторые очень продвинутые.
LVV>Бросили все.

И перешли в С# что ли?

LVV>По причине тормознутости.


Больше .hpp файлов и header-only библиотек, как в бусте. Но зачем? Не всегда надо. Плюс надо некоторый physical design думать и отделять фасад API от impl классов.
Модули скоро в С++20 (+) завезут, но это не всем поможет, особенно тем, кому тулчейн не позволяет — некоторые плавно со скрипом из C++03 в С++11 вылазят. AIX xlCC++, например.
Это все, например в финансах, очень обычно.

LVV>На удивление Rider у них — великолепная система.


Ну конечно, C# и dotnet /NetFramework Core. Сравнили ужа с ежом
Rider это ужк как эволюция решарпера (кто в теме), но кросс платформа и выход из Visual Studio 32 bit plugin тупика.
Хотя JetBrains утверждает, над этими вещами разные команды работают. Ну это и логично.

Visual Studio (не vscode) — это мощно, и своего рода золотой стандарт IDE (не все версии). Можно в кросс платформ, но надо уметь.
Но кросс платформа уже нужна. в 2020-то году. Apple ARM Arch is coming, CreatorCray не даст соврать

LVV>Некоторые пацаны сейчас работают, а я попробовал еще предрелиз.

LVV>ВСЕ хвалят, кто работает.
LVV>Видимо, по сравнению со Студией — маленькая, делает все.

нету дизайнера форм. А кому-то надо.
my $.02
Отредактировано 08.07.2020 5:07 .... . Предыдущая версия .
Re[2]: Модульные системы программирования
От: ole! США http://files.rsdn.org/4543/rsdn.gif
Дата: 08.07.20 05:24
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

LVV>Модули в Си-подобных языках отсутствуют как в принципе!

LVV>Вот сейчас в С++20 что-то сделали, но очень странное.

да, это спорная тема. Почему то всегда находится кто-то, кто сравнит с Rust, etc.

Тут надо проникнуться и понять, что комитет по С++ достичь хочет и послушать Bjarne, Gabriel Dos Reis, Rainer Grimm и людей из WG21 C++, SG15. Почитать спеки с http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
Не всем нравится, но это просто работает по другому и немного для других целей задумано. Backwards compatibility как одна из причин, почему это так.
my $.02
Отредактировано 08.07.2020 5:40 .... . Предыдущая версия .
Re[7]: Модульные системы программирования
От: LaptevVV Россия  
Дата: 08.07.20 07:17
Оценка:
LVV>>Я у себя в Астраханском и сам попробовал, и пацанам сказал — давайте в CLion.
LVV>>Попробовали многие. Некоторые очень продвинутые.
LVV>>Бросили все.
O>И перешли в С# что ли?
Не. Просто если на С++, то используют QtCreator, Студию, Code::Blocks...
LVV>>На удивление Rider у них — великолепная система.
O>Ну конечно, C# и dotnet /NetFramework Core. Сравнили ужа с ежом
O>Rider это ужк как эволюция решарпера (кто в теме), но кросс платформа и выход из Visual Studio 32 bit plugin тупика.
O>Хотя JetBrains утверждает, над этими вещами разные команды работают. Ну это и логично.
O>Visual Studio (не vscode) — это мощно, и своего рода золотой стандарт IDE (не все версии). Можно в кросс платформ, но надо уметь.
O>Но кросс платформа уже нужна. в 2020-то году. Apple ARM Arch is coming, CreatorCray не даст соврать
Наши пацаны практически поголовно перешли на него + Студия 17/19 (если Rider'a в чем-то не хватает).
O>нету дизайнера форм. А кому-то надо.
Ну, и в NET Core нет визуальной части.
Сделали веб-интерфейс в наших системах.
Нормально выглядит.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[7]: Модульные системы программирования
От: CreatorCray  
Дата: 08.07.20 07:52
Оценка: +1
Здравствуйте, ole!, Вы писали:

O>Visual Studio (не vscode) — это мощно, и своего рода золотой стандарт IDE (не все версии).

До сих пор дома для pet projects юзаю 2008ю со сторонним компилером. После гемора с XCode там просто душой отдыхаешь. Всё работает, всё летает, всё удобно.

O>Но кросс платформа уже нужна. в 2020-то году.

Редактор может быть на любой платформе. Я в вижуалке код в BSD ядро писал, собиралось на buildserver через ssh, вывод компилера появлялся в Output window в IDE.

O>Apple ARM Arch is coming, CreatorCray не даст соврать

Да уже вовсю пришёл.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[2]: Модульные системы программирования
От: varenikAA  
Дата: 08.07.20 08:05
Оценка: +1 -3 :)
Здравствуйте, ole!, Вы писали:

O>И вот интересно, на самом деле. Чем Уолтер Брайт пользуется для работы с кодом? В большом объеме кода, 100500 KLOC? В чём зло IDE?


Классическая IDE аналогичная VS(C#) поощеряет начинающего программиста написать плохо спроектированную, нерабочую программу и потом
доводить ее до ума с помощью пошагового отладчика, ставя заплатки тут и там.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[3]: Модульные системы программирования
От: Privalov  
Дата: 08.07.20 08:43
Оценка:
Здравствуйте, varenikAA, Вы писали:

AA>Классическая IDE аналогичная VS(C#) поощеряет начинающего программиста написать плохо спроектированную, нерабочую программу и потом

AA>доводить ее до ума с помощью пошагового отладчика, ставя заплатки тут и там.

Угу. Перфокарты, IEBUPDTE — наше всё!
Отредактировано 08.07.2020 8:44 Privalov . Предыдущая версия .
Re[8]: Модульные системы программирования
От: Ночной Смотрящий Россия  
Дата: 08.07.20 09:46
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Ну, и в NET Core нет визуальной части.


Уж год как есть.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: Модульные системы программирования
От: LaptevVV Россия  
Дата: 08.07.20 09:53
Оценка:
LVV>>Ну, и в NET Core нет визуальной части.
НС>Уж год как есть.
Да, я мельком видел, что они там чего-то сделали.
Да фиг с ней...
Пацана как сделали веб-интерфейс — так и не стали переделывать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Модульные системы программирования
От: Cyberax Марс  
Дата: 08.07.20 22:41
Оценка: +3
Здравствуйте, varenikAA, Вы писали:

AA>Наткнулся на описание Oberon (система Black Box).

AA>https://oberoncore.ru/library/gubanov_sekrety_modulnyh_sistem
AA>Внезапно осознал, что мало какие ЯП являются модульными.
Бред.

AA>И еще поразило, вот это:

AA>

AA>Ведь .Net система больше похожа на монотонно растущую монолитную программу, чем на динамически расширяемую модульную систему. Для удобства программирования «на больших масштабах» предлагается использовать не средства языка, а вспомогательные инструменты интегрированной среды разработки.

Ерунда.

IDE — это средство работы с большими кодовыми базами (навигация и автокомплит, прежде всего). Никакой "модульный язык" это не заменит. Кодогенерация — это скорее бесплатный бонус, и далеко не всегда он нужен.

Просто на Обероне ничего существенного не написано, вот они и не знают какие проблемы бывают при работе в реальных условиях.
Sapienti sat!
Re[2]: Модульные системы программирования
От: varenikAA  
Дата: 08.07.20 23:54
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, varenikAA, Вы писали:


AA>>Наткнулся на описание Oberon (система Black Box).

AA>>https://oberoncore.ru/library/gubanov_sekrety_modulnyh_sistem
AA>>Внезапно осознал, что мало какие ЯП являются модульными.
C>Бред.

AA>>И еще поразило, вот это:

AA>>

AA>>Ведь .Net система больше похожа на монотонно растущую монолитную программу, чем на динамически расширяемую модульную систему. Для удобства программирования «на больших масштабах» предлагается использовать не средства языка, а вспомогательные инструменты интегрированной среды разработки.

C>Ерунда.

C>IDE — это средство работы с большими кодовыми базами (навигация и автокомплит, прежде всего). Никакой "модульный язык" это не заменит. Кодогенерация — это скорее бесплатный бонус, и далеко не всегда он нужен.


C>Просто на Обероне ничего существенного не написано, вот они и не знают какие проблемы бывают при работе в реальных условиях.


Тут дело в качестве программирования. Если программист с первых дней надеется только на магию IDE(О! у нас же есть пошаговый отладчик,"счастливой отладки программисты на X!") да еще умножить
на сложные конструкции языка в которых легко запутаться(привет siwtch по enum и switch по объекту(паттернматч), например), то мы получим то, что заслужили — сложную, полную скрытых багов систему.
В противовес IDE-шным языкам Oberon(Component Pascal) пердлагает минимум средств(но отлично продуманных — в его разработке был использован научный подход), используя которые программист дисциплинируется
писать алгоритмы правильно.
Скажу больше — модуль в обероне это не просто единица исходного кода, это именно модуль(сборка в дотнете), но только в режиме один файл — одна сборка. В отличие от дотнета модуль может быть выгружен, если на него нет ссылок.
Так же он может быть изменен, при условии, что используемые клиентским кодом функции не меняют свой интерфейс.
Это лишь часть того что есть в обероне, и да оберон не популярен у мэйнстрима, но существует пояс оберона в евразии, где он активно используется уже есть кросскомпиляторы и в js и в другие ахритектуры(арм и пр).

И последнее, java, dotnet использовали концепции оберона. Go прямо пишут что были им вдохновлены.
Но к сожалению в java и dotnet рулят корпорации, эти языки и платформы поддерживаются деньгами.
Чтобы были клиенты им постоянно нужно что-то новое предлагать.


Простота Оберонов проявляется в следующих характеристиках:
(1) в малом объеме описаний этих языков, обычно в районе 20 стр.;
(2) в быстроте и компактности компилятора (компилятор первоначального Оберона имел размер около 40К; вообще компиляторы Оберонов более чем на порядок превосходят по быстродействию компиляторы С++).

Н.Вирт, создавший Оберон, является авторитетом и в проектировании компиляторов, причем язык проектировался одновременно с созданием компилятора. Поэтому не удивительно, что Обероны поддаются быстрой и эффективной компиляции, а код, который порождают компиляторы Оберона, чист и эффективен даже без оптимизации.

Именно благодаря этому Обероны нашли первые промышленные применения при создании встроенных управляющих систем, где ресурсы жестко ограничены (например, полетным весом беспилотного летательного аппарата), а требования на надежность очень высоки (стоимость необнаруженного до полетных испытаний программного дефекта даже в малом беспилотнике — несколько тысяч у.е., поскольку такой дефект как правило означает потерю аппарата; максимальная известная стоимость одной программной ошибки — полмиллиарда у.е., это стоимость потерпевшей катастрофу на взлете европейской космической ракеты Ариан-5 в 1996 г.).
☭ ✊ В мире нет ничего, кроме движущейся материи.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.