LINUX.ORG.RU

Идеальная система модулей в языке программирования

 , ,


0

3

Навеяно одной из соседних тем. Стало интересно, что вообще люди думают по этому поводу.

Какой бы вы хотели видеть систему модулей?

Тут можно выделить ряд вопросов.

Должны ли модули быть файлами(один файл - один модуль) или они должны декларироваться в коде? Или это можно как-то скомбинировать?

Должен ли модуль быть единицей инкапсуляции или же это лучше оставить системе типов(классы в случае ООП)?

Должен ли модуль формировать пространство имен? Как должен работать import?

Нужно ли явно отделять интерфейс модуля от реализации в коде(или даже их стоит по разным файлам разносить)?

Как система модулей сочетается с системой пакетов/зависимостей? Как сочетается с системой сборки?

И т.д. и т.п.

Делитесь мыслями и идеями=)


Ответ на: комментарий от den73

Для eval (и intern) задача поиска идентификаторов никак не решается вне зависимости от возможности переименования.

monk ★★★★★
()
Ответ на: комментарий от den73

Да, про него, родимого.

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

monk ★★★★★
()
Ответ на: комментарий от monk

Этого уже достаточно, чтобы эти два блока пришлось писать в одном модуле.

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

Причем в том же питоне можно сделать отложенный импорт и такой проблемы нет как класса.

A1
()
Ответ на: комментарий от A1

Ну они же не большие.

Бывают большие: Идеальная система модулей в языке программирования (комментарий)

Проблема даже выеденного яйца не стоит.

В целом да. Идеальная система модулей в языке программирования (комментарий)

Причем в том же питоне можно сделать отложенный импорт

Потому что в нём компиляции нет.

monk ★★★★★
()
Ответ на: комментарий от monk

В смысле, запустил юнит-тесты — все ошибки по внешним идентификаторам должны вылезти.

У тебя всегда есть юнит-тесты? Даже если это чужой старый код? В общем, я понял основную причину неиспользования поиска тобой: тебе не попадается позднее связывание. Главное, чтобы я был с правильной планеты.

Кстати, ещё одно частое использование поиска - это найти фрагмент текста сообщения об ошибке.

А сегодня у меня есть массив Choice из 60 элементов, которые не документированы (это чужой код). Я уже поискал число 23 и Choice[23]. Осталось повторить процедуру ещё 59 раз. Не знаю, что буду делать с числами меньше 10.

Касаемо eval - да, все вхождения ты не найдёшь, но многие найдёшь.

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

И особенно в ситуации, когда ты не знаешь, что делать, изучаешь код, придумываешь те или иные решения. Может быть, тебе и не надо удалять идентификатор.

Ну ладно, всё, я понял насчёт поиска и что мог - тоже сказал. Думаю, данную ветку тоже можно закрывать.

den73 ★★★★★
()
Ответ на: комментарий от monk

Например, есть окно, а у него есть меню. В меню есть пункт «новое окно», которые создаёт новое такое же окно. Как разделить меню и окно? А кода описания у обоих может быть достаточно много.

Я мало работал с GUI, но мне кажется, что это решается всяческими MVC. Нет?

forCe
() автор топика
Ответ на: комментарий от den73

Начитались люди книжек, а жизни не знают.

Как раз жизнь и учит не пихать все в один большой модуль... И разнос одного модуля по нескольким файлам тут только усугубляет проблему...

forCe
() автор топика
Ответ на: комментарий от den73

Мне вот интересно, если можно добавлять имена с переименовыванием, то есть ли там поиск по файлам.

Где там? Это явно задача IDE.

forCe
() автор топика
Ответ на: комментарий от forCe

Да, это задача IDE. В Racket она есть.

Я думаю, что для динамических языков нужно смотреть в сторону dpkg.

den73 ★★★★★
()
Ответ на: комментарий от den73

Да, это задача IDE. В Racket она есть.

Не понял. Racket - это язык программирования. Я могу писать на racket в emacs'е.

Не надо смешивать IDE и язык программирования.

forCe
() автор топика
Ответ на: комментарий от forCe

deb - пакеты - это тоже система модулей, хотя и не из ЯП.

Касаемо IDE, если рассмотреть ЯП без инструментов, то о производительности труда нельзя сказать абсолютно ничего. Человек работает не с абстрактным ЯП, а с инструментами, будь то IDE, EMACS или ещё что-то. В зависимости от особенностей ЯП некоторые инструменты для него создать легко, а некоторые невозможно. Поэтому при анализе ЯП нужно думать о том, какие инструменты к нему могут быть созданы, как они будут использоваться, сравнить это с лучшими практиками других языков и только тогда можно говорить об идеальности.

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

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

deb - пакеты - это тоже система модулей, хотя и не из ЯП.

Так. А динамические языки тут при чем?

Человек работает не с абстрактным ЯП, а с инструментами, будь то IDE, EMACS или ещё что-то.

Да, но разные пользователи одного и того же языка пользуются разными инструментами.

Поэтому при анализе ЯП нужно думать о том, какие инструменты к нему могут быть созданы

Ну мы вроде о нормальных языках говорим. Т.е. никаких проблем в работе текстовых редакторов быть не должно, а IDE можно будет создать.

forCe
() автор топика
Ответ на: комментарий от den73

наивысшую производительность труда разработчика

Как же умиляет эта мантра из уст наемных дурачков. Ты так переживаешь за рабовладельцев, прям ночами не спишь, обдумываешь: как же мне повысить выработку. Молодец, продолжай. Хотя и без тебя уже RAD во все поля, и эксплуатация черни возросла многократно по сравнению с 90-ми даже. Качество продукта соответственно упало.

anonymous
()
Ответ на: комментарий от anonymous

Как же умиляет эта мантра из уст наемных дурачков. Ты так переживаешь за рабовладельцев, прям ночами не спишь, обдумываешь: как же мне повысить выработку.

А ты предлагаешь за чужие деньги делать никому не нужные и дорогие системы?

forCe
() автор топика
Ответ на: комментарий от bvn13

а что там за секреты? механизм динамических библиотек =)

MikeDM ★★★★★
()
Ответ на: комментарий от forCe

Так. А динамические языки тут при чем?

Есть аналогия, если ты имел дело с лиспом, то она довольно очевидна.

Среда состоит из взаимодействующих модулей, которые могут динамически добавляться и, что самое сложное, меняться и удаляться. Большинство языков - статические и проблемы удаления модуля в них нет. Лисп, SQL и Оберон - те динамические, о которых мне хоть что-то известно, везде разный подход к удалению. debian можно добавить в этот ряд. В Питоне вроде тоже можно перезагрузить модуль.

а IDE можно будет создать.

И до момента создания IDE нет смысла говорить об идеальности. Хороший язык без поддержки инструментами будет хуже, чем плохой с хорошими инструментами.

den73 ★★★★★
()
Ответ на: комментарий от den73

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

Ты про динамические библиотеки не слышал?

anonymous
()
Ответ на: комментарий от den73

Оберон - те динамические

Оберон - статический язык. Если ты, конечно, имел в виду типизацию.

anonymous
()
Ответ на: комментарий от den73

Зарегистрируйся.

Анонимизируйся

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.