Ищутся статически типизированные контейнеры для Common Lisp

Ты это к чему?

Он это к тому, что создание языка начинается с идеи предназначения языка, а Дениска мутит язык ради интеграции с ИДЕ.

Он это к тому, что создание языка начинается с идеи предназначения языка, а Дениска мутит язык ради интеграции с ИДЕ.

может как раз этого миру и не хватает, мало ли

Вообще говоря, пока чётких научных аргументов нет, я бы поостерёгся говорить «надо начинать с идеи предназначения и никак иначе». кто его знает, это надо диссер писать. Много языков были с идеями, да где они?

Да, хаскель - пример очень интересный. Ява тоже. Но тот же c# к примеру это банальщина вроде «мы сделаем свою яву ибо западло башлять другим, лучше уж себе оставить». У яра немного по -другому: «а давайте так попробуем, может оно кому-то понравится, а там поглядим»

Ты это к чему?

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

пока чётких научных аргументов нет

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

получается, что проект «небоскрёба» создаётся по ходу строительства оного - не хотел бы я в таком очутиться...

А на чём пишешь? Потому что все более-менее активно развивающиеся языки такие небоскрёбы и представляют: сначала строится небольшой и аккуратно спроектированный (и то не всегда) домик, а дальше его достраивают, причём направление строительства меняется.

оба инструмента имеют одну и ту же цель — создание программного продукта.

Создание экскаватора не имеет смысла, ведь уже есть инструмент для «создания ям» - лопата.

Это я не в защиту Яра, если что, хотя и тут автор, вроде как, старается «улучшить» всё, что можно.

По-моему бредовенько.

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

Или предлагаешь на каждую параметризацию отдельный gethash определять?

Да, как в шаблонах плюсов.

https://www.artlebedev.ru/kovodstvo/sections/135/#07

У тебя ж статически типизированный язык(я про твой яр).

Ни за чем, и именно этим статически типизированный контейнер отличается от динамически типизированного. Но Яр содержит и динамическую типизацию тоже - он похож в этом на CL и C#. Есть тип «object» aka «всё что угодно» aka t aka variant. Плюс к тому есть вывод типов (заимствованный из SBCL).

«для популярности языка наличие IDE всё-таки нужно»

Из этого следует, что для популярности языка нужно IDE, но из этого не следует что сначала нужен язык. Ты берёшь свой любимый EMACS или что там у тебя любимое и делаешь из него IDE, это можно делать постепенно, по мере воплощения языка, и IDE не обязательно должно быть написано на этом же языке.

проект «небоскрёба» создаётся по ходу строительства оного

ЕМНИП, в K&R написано, что Си возникал именно так. Если ты посмотришь на все языки, то не увидишь ни одного, к-рый бы не изменился со временем.

Язык — это средство для создания ПО, то есть, инструмент.

Лол :-) Язык - это набор конструкций для описания чего-либо, в частности, ПО :-) А инструментом, в данном случае, является редактор кода или IDE :-)

Поэтому, создание инструмента под инструмент как самоцель не имеет никакого смысла, и, более того, является извращением здравого смысла, оба инструмента имеют одну и ту же цель — создание программного продукта.

Понимаешь ли, если наворотить такое гипер контекстно-зависимое гамнецо, как например, цепепе, то для такого языка едва ли можно создать качественную IDE в разумно-обозримые сроки :-) Противоположный пример - простая как пробка Java, для которой на рынке самые лучшие IDE :-)

Это на весь лишп распространимо.

Или предлагаешь на каждую параметризацию отдельный gethash определять?

Да, как в шаблонах плюсов.

Ахаха :-) Страуструп и его последователи аплодируют стоя :-) Лол :-)

Если ты посмотришь на все языки, то не увидишь ни одного, к-рый бы не изменился со временем.

Simula?

Новый код или свой код мне проще писать без IDE, где IDE начинает только мешать

Если твой проект состоит из 1 - 20 файлов (у каждого индивида свой верхний предел) по 250 строк в каждом (усреднёно), то работать без IDE ещё можно относительно эффективно :-) Потом продуктивность начнёт неминуемо падать :-) И ничего поделать с этим нельзя, кроме как воспользоваться усилителем - IDE :-)

IDE - это не сраный автокомплит :-) IDE - это прежде всего навигация и кодовой базе :-)

IDE - это рефакторинг - даже при банальном переименовании инклюда без IDE нужно вручную менять директивы в каждом файле, который этот инклюд включает; а с IDE это делается автоматически, никакими sed/grep/awk/прочая хрень это не заменишь, даже если порвать на себе рубаху для самоутверждения «какой я специалист, могу без IDE» :-)

IDE- это эффективная работа с документацией :-) Т.е. это когда не надо лезть на сайт или в pdf чтобы найти описание функции, а достаточно нажать хотку и нужна документация мгновенно появится :-)

Ну и т.д. и т.п. :-) Можно конечно «работать» исключительно в вимо-емаксо-саблаймах-фарах мэнэджэрах, но это, скорее, не работать, а фигнёй страдать :-) Лол :-)

Если твой проект состоит из 1 - 20 файлов (у каждого индивида свой верхний предел) по 250 строк в каждом (усреднёно), то работать без IDE ещё можно относительно эффективно :-) Потом продуктивность начнёт неминуемо падать :-) И ничего поделать с этим нельзя, кроме как воспользоваться усилителем - IDE :-)

Зачем одновременно работать с 20 файлами? А если работаешь с одним файлом, а остальные 19 — библиотеки, то держать их открытыми не надо.

Зачем одновременно работать с 20 файлами?

Не знаю :-) Но я не говорю про «одновременно», я говорю про «состоит» :-) Средний и крупный проект состоит из нескольких десятков и сотен файлов :-) Работать с кучей файлов, по которым разбросаны абстракции без IDE непродуктивно :-) Вообще говоря, работать с файлами при разработке кода неправильно :-) Правильно работать с абстракциями проекта :-) Не должно быть вообще важно в каком там файле лежит класс или функция :-) Этот дебилизм был вынужденной мерой для ускорения компиляции всяких цепепе и це, и чтобы всякие ODR соблюдать :-) Там же изобрели всякую галиматью под названием «forward declarations» и носятся с этим всем бредом несколько десятилетий :-) Вон, стандарты рисуют каждые 4 года, а модули сделать не могут, чтобы работать нормально :-) Работайте с файлами через вимы и емаксы и всё будет хорошо, header-only рулит, лучше ничего нет :-) Лол :-)

Ну ладно, может и есть такие, но всё, с чем мне приходилось работать, менялось. Да и вакансий по Симуле что-то не видно.

Работать с кучей файлов, по которым разбросаны абстракции без IDE непродуктивно

Если они все в одном файле, это гораздо грустней. А в целом, смотря как работать. В многооконной среде и без IDE удобно. Единственная вещь, которая есть в IDE и которую не очень удобно делать на коленке — «перейти к определению». С другой стороны, ни в Racket, ни в Haskell потребности в такой функции и не было ни разу. Документации и типа/контракта хватает.

Не должно быть вообще важно в каком там файле лежит класс или функция :-) Этот дебилизм был вынужденной мерой для ускорения компиляции всяких цепепе и це, и чтобы всякие ODR соблюдать

Да ладно. В java класс должен совпадать с именем файла. В Haskell модуль должен совпадать с именем файла. В Racket также файл = модуль. Так что файлы весьма удобный способ разбиения кода.

Если они все в одном файле, это гораздо грустней.

Ну так потому то их и разбивают :-) Просто не существует инструмента для более совершенного разделения кода, чем «просто взять и поделить на файлы» :-) Лол :-)

С другой стороны, ни в Racket, ни в Haskell потребности в такой функции и не было ни разу. Документации и типа/контракта хватает.

Это когда повторно используешь чей-то код, который «просто работает» :-) А в проекте над которым работаешь что, нет потребности переходить к определению функции? :-) Они сами себя рефакторят и сами себя усовершенствуют что-ли? :-) Ай да Рэкет :-)

Да ладно. В java класс должен совпадать с именем файла. В Haskell модуль должен совпадать с именем файла. В Racket также файл = модуль. Так что файлы весьма удобный способ разбиения кода.

Авторы Java, Racket, Haskell просто натянули классы/модули на файлы, навязав таки пользователям работать с файлами, но смотреть на них как на классы/модули :-) При этом в Java есть понятие пакета, в который могут входить какие-угодно классы :-) Я догадываюсь зачем это было сделано - потому что качественные IDE появляются не сразу, а язык надо распространять :-) Сейчас для Java есть IDE, и необходимость манипулировать файлами сводится на нет :-) На кой хрен это надо, когда можно работать с классами, которые где-то там в недрах, про которые знает IDE? :-) Это как работать с СУБД, заморачиваясь в какой файл будет занесён результат INSERT ... :-) Это очень важно знать, да? :-)

А в проекте над которым работаешь что, нет потребности переходить к определению функции? :-) Они сами себя рефакторят и сами себя усовершенствуют что-ли? :-) Ай да Рэкет :-)

Файл-модуль маленький (500 строк). Контрактная система позволяет ошибку определять с точностью до модуля. Для усовершенствования функции не требуется открывать другие функции. В отличие от ООП проблемы хрупкого базового класса здесь нет. В Haskell аналогично.

Могу представить работу с двумя файлами: когда программу дробишь на более мелкие цельные модули. А вот зачем их больше двух?

А вот зачем их больше двух?

чтобы использовать некоторые из них в двух проектах. Может быть, даже в целых трех.

Для усовершенствования функции не требуется открывать другие функции.

Т.е. функция модуля M1 не может зависеть от функций модуля M2? :-) Лол :-)

Могу представить работу с двумя файлами: когда программу дробишь на более мелкие цельные модули. А вот зачем их больше двух?

В смысле? :-) Ну есть кодовая база на 100000 строк :-) Куча классов и функций, макросов и констант :-) Если нет средства лучше чем «взять и по файлам поделить», то сидишь и делишь по файлам :-) 100000 / 2 = 50000 строк на файл, два файла модуля, как ты и хочешь :-) Так? :-)

чтобы использовать некоторые из них в двух проектах. Может быть, даже в целых трех.

Так для этого не надо работать с ними одновременно. Всё равно ведь вычленяешь модули по очереди.

Т.е. функция модуля M1 не может зависеть от функций модуля M2? :-) Лол :-)

Может. Но не может зависеть от реализации этих функций. Когда используешь STL, смотришь документацию или постоянно к исходникам функций переходишь?

два файла модуля, как ты и хочешь

Модулей может быть много. Но работаешь всегда максимум с двумя одновременно.

Может. Но не может зависеть от реализации этих функций. Когда используешь STL, смотришь документацию или постоянно к исходникам функций переходишь?

Да ладно :-) А если не STL, а Velosiped, в котором функция, от которой зависит функция модуля, где найдена ошибка, нуждается в рефакторинге? :-) Я же говорю, когда зависимости «просто работают» (как STL), то нет нужды смотреть в реализацию :-) А когда foo() зависит от bar() и обе в одном и том же проекте, и при рефакторинге первой обнаруживается необходимость рефакторинга второй, то всё не так радужно, как ты описываешь :-)

Модулей может быть много. Но работаешь всегда максимум с двумя одновременно.

Не понимаю, о чём ты :-)

А когда foo() зависит от bar() и обе в одном и том же проекте, и при рефакторинге первой обнаруживается необходимость рефакторинга второй, то всё не так радужно, как ты описываешь

Если выясняется, что модуль, в котором bar(), не выполняет свою задачу, то закрываешь модуль с foo(), открываешь c bar(), исправляешь, проверку исправления найденного бага вносишь в виде юнит-теста, чтобы к нему больше не возвращаться. Работать в это время с foo() не надо.

Но работаешь всегда максимум с двумя одновременно.

Не понимаю, о чём ты :-)

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

Если выясняется, что модуль, в котором bar(), не выполняет свою задачу, то закрываешь модуль с foo(), открываешь c bar(),

Т.е. надо перейти к определению bar() :-) А ты говорил, что не надо :-)

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

С foo() надо работать сразу после завершения работы над bar() :-) Но сначала надо вернуться к определению foo () :-) А как это сделать? :-) Все делают так: открывают файл с модулем, где определена foo() [при этом, сначала надо напрячь извилины, чтобы вспомнить, в каком из сотни другой модулей (аля файлы) определена эта foo()], находят foo() в открытом файле и правят :-) И так целыми днями :-) [А в цепепе и ночами - круглосуточно :-)]

Я же хочу просто дать указание «перейти к определению foo», чтобы IDE дала мне подсказку: что функций, похожих на имя «foo» в проекте 5 штук, чтобы я выбрал из списка :-) Вот что в моём понимании IDE, не сраный автокомплит и работа с файлами :-)

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

Да :-) Книг, написанный тобой, может быть тысячи :-) Но когда в один прекрасный момент ты пишешь очередную книгу и на 523 странице обнаруживаешь нестыковку сюжета, то вынужден лопатить всё написанное, чтобы зарефакторить :-) Так вот рефакторить можно на печатной машинке, а можно на компьютере Notepad, а можно на компьютере с Emacs :-) Ну ты понял :-) Лол :-)

С foo() надо работать сразу после завершения работы над bar()

Вообще-то нет. Если при тестировании foo выяснилось, что есть ошибка в bar, значит foo уже написана. Надо просто продолжать работу над тем модулем, где foo.

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

на 523 странице обнаруживаешь нестыковку сюжета ... можно на компьютере с Emacs

Так IDE — это не Emacs. IDE для писателя — это некий каталогизатор действующих лиц, сцен, и связей между ними. Примерно такой монстр: https://www.autostraddle.com/wp-content/uploads/2012/11/scrivener.jpg

Вообще-то нет. Если при тестировании foo выяснилось, что есть ошибка в bar, значит foo уже написана. Надо просто продолжать работу над тем модулем, где foo.

Ты почему-то рассматриваешь только вариант, когда нужно исправить ошибку :-) Я же говорю о рефакторинге — это когда нужно улучшить/изменить кодовую базу :-)

Так IDE — это не Emacs. IDE для писателя — это некий каталогизатор действующих лиц, сцен, и связей между ними. Примерно такой монстр: https://www.autostraddle.com/wp-content/uploads/2012/11/scrivener.jpg

Ну да :-)

Так IDE — это не Emacs. IDE для писателя

Кстати, ты в чём пишешь на Racket? :-) Если в drr, то как тебе она? :-) Реально ли в drr писать продуктивно средние и большие проекты, или она только для полных новичков, чтобы им стрелочки рисовать? :-)

Перестань делать комбайн aka новый с++, и проблемы сами собой решатся

Если в drr, то как тебе она? :-)

Из неожиданностей: фактически нет автодополнения. Оно есть только по всем символам из справки (а не по используемым модулям).

В остальном всё достаточно удобно: переход к определению, переименование символа (с учётом привязок именно к этому символу, а не все одноимённые),

Реально ли в drr писать продуктивно средние и большие проекты, или она только для полных новичков, чтобы им стрелочки рисовать?

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

библиотеки, то держать их открытыми не надо

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

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

сначала строится небольшой и аккуратно спроектированный (и то не всегда) домик, а дальше его достраивают, причём направление строительства меняется.

Да не вопрос: построили «домик» - написали под него IDE. Перестроили домик - дописали IDE. И т.д. Но сначала «домик» (любой величины, но более менее законченный) - а потом IDE. А иначе можно оказаться в ситуации постоянно недоделанного и «домика», и IDE - и пользоваться таким будут только отчаянные фаны.

Ты берёшь свой любимый EMACS или что там у тебя любимое и делаешь из него IDE, это можно делать постепенно, по мере воплощения языка

Придумал супер-пупер фичу «super-loop», кое-как воплотил - побежал дописывать IDE, тестить, через вермя понял, что фичу надо исправить - исправил - побежал дописывать и тестить IDE. Т.е. вместо «придумал -> написал -> отладил» получаем «придумал -> написал -> переписал IDE -> отладил IDE -> отладил фичу (и слегка отрефакторил по ходу отладки -> сломал IDE) -> отладил IDE», через день придумал версию +1 - начинай сначала... Это даже не в противогазе на лыжах в гамаке...

может это я такой беспамятный, но во время «горячей» фазы разработки всё время приходится смотреть что я там написал в другом файле и паралельно править если тут надо по другому сделать

Обычно это свидетельствует об отсутствии фазы проектирования даже в виде «сесть и представить, какой модуль за что именно должен отвечать». Или копипасте из другого файла, что подразумевает недостаточное разбиение на функции/макросы.

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

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

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

в постановке задачи не учтены все факторы

И это случается сплошь и рядом, особенно в активно развивающемся проекте.

Обычно это свидетельствует об отсутствии фазы проектирования даже в виде «сесть и представить, какой модуль за что именно должен отвечать».

Ты опять рассматриваешь частный случай, а именно, первоначальный этап разработки с нуля :-) Если ты рассмотришь этап рефакторинга уже написанного кода, то картина будет другой :-) Вот открой историю коммитов какого-нибудь SBCL :-) Посмотри, сколько файлов затронуто тем или иным коммитом :-) Бывает по-разному, но встречаются пачки и по 10 и по 20 файлов, наверняка :-)

А иначе можно оказаться в ситуации постоянно недоделанного и «домика», и IDE - и пользоваться таким будут только отчаянные фаны.

Это больше зависит от ресурсов, чем от «стратегии».

Если ты рассмотришь этап рефакторинга уже написанного кода, то картина будет другой

А здесь мне гораздо больше, чем любой IDE, помогает grep -R.

Ну какая IDE мне даст список вызовов всех предупреждений, где в тексте встречается «conflicting with its asserted type»?

А здесь мне гораздо больше, чем любой IDE, помогает grep -R.

Знаем знаем :-) Запускаешь такой M-x grep, потом дописываешь аргументы и вперёд :-) Потом такой по C-x ` ходишь по файлам и вручную (пусть даже с помощью макроса) исправляешь эти файлы :-) Очень весело, да :-)

С другой стороны, какой grep -R сможешь автоматически сгенерировать определения объявленных функций в том же цепепе? :-) Или банально функцию переименовать автоматически во всём проекте? :-)

Ну какая IDE мне даст список вызовов всех предупреждений, где в тексте встречается «conflicting with its asserted type»?

Лол :-) Да хоть та же IDEA :-)

что ж, возможно. не могу сказать что уж совсем ни «сесть и представить», но проектирования может быть маловато.

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

Это даже не в противогазе на лыжах в гамаке...

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

Как разработчик языка и IDE могу тебе сказать, что это довольно трудоёмкое дело. Но в целом его сделать можно.

Я и не спорил с «можно». Я искренне не нахожу оправданий для «нужно» кроме как «я так хочу». Хозяин - барин...

ок.