Комментарии 29
Удивляет какое продолжительное время Араки тащит это на себе, при этом так же удивляет объём и то, что многие вещи не бросаются на начальной стадии, как часто бывает когда ресурсов мало.
Помню как в issues к Nim спросили про аналог концепции владения из Rust и нету ли планов это перенять, Араки ответил что в настоящий момент планов таких нету, но подумать над этим стоит, и через пару релизов появился paper с предположением как это реализовать в Nim, и вот уже в Nim присутсвуют такие вещи как -gc:arc и -gc:orc, но пока эти gc не включены по-умолчанию.
Andreas Rumpf: Nim ARC/ORC (NimConf 2020) - YouTube
А ещё ним, несмотря на всё что в нём есть, производит ощущение цельности! И, может быть, это как раз благодаря небольшой команде (он там, всё-таки, не один, если быть честными)
По управлению памятью, кстати, кажется, тут ещё ссылка на эту статью будет уместна:
Введение в ARC/ORC в Nim
Возможно укороченная запись != обязательно лаконичная. Лаконичность - краткое и ясное выражение мыслей
Малое количество букв в законченном предложении на том или ином языке превращают это предложение в шум при неправильном контексте, либо в информацию в правильном :). Тут нельзя эксклюзивно противопоставлять лаконичность многословности, оба варианта должны быть хорошо поддержаны в языке - нужно уметь лаконично описывать частые ситуации и однозначно и самоописательно описывать редкие :).
В качестве критики универсальности языка Nim (она точно такая же, как к языку Си++): авторы пытаются абстрагироваться от всех возможных (вероятных в будущем) библиотек каких угодно алгоритмов и подходов, как бы заранее предоставив выразительные средства для их сочинения. Это будто не язык, а фреймворк для создания языков. А потому прочесть "любую" строчку кода на Nim, зная только этот самый Nim, в общем случае не получится, придётся вникать в предметную область, в подходы, выбранные программистами конкретного проекта, вникать в выбранный набор ограничений.
Любая достаточно сложная система на любых языках (и их сочетании) приводит к появлению в проекте своего собственного языка (DSL), явно или неявно реализованного программистами, который торчит из конфигов проектируемой системы или структур данных персистентного хранения. Nim в этом смысле (как я понял авторов) выступает религиозным и неэффективным ограничением: пишите и конфиги на том же компилируемом языке, и хранимые структуры описывайте, правда, вам придётся сочинить это подмножество ограничений для конфигов / структур, а потом научить их остальных программистов проекта на Nim :). В общем, романтическая мечта об "едином языке", несовместимая с реальностью. Разницы между написанием проекта на [Ямл + Си] (например) и [Ним.Ямл + Ним.Си] нет никакой (кроме замыкания разработки на авторах Nim) :).
Nim в этом смысле (как я понял авторов) выступает религиозным и неэффективным ограничением: пишите и конфиги на том же компилируемом языке, и хранимые структуры описывайте, правда, вам придётся сочинить это подмножество ограничений для конфигов / структур, а потом научить их остальных программистов проекта на Nim :)
какой-то LISP получается...
Да, будто бы целятся и в LISP (в роли "клея" - декларативного языка склейки логики системы), и в FORTH (в роли "бутстрапа" - рекурсивно самоопределяющего уровни системы языка). Эти языки тоже "беспредельно мощные", но таки поселились в своих довольно ограниченных практических нишах по итогу, идея гиперуниверсальности не взлетает :). Но это я оч со стороны и умозрительно обобщаю, сам на Nim не программирую :).
Наконец, должен быть только один язык программирования для всего.
Всегда бесило вот такое навязывание единственного, расово верного инструмента.
Инструменты надо выбирать в соответствии с задачами (и некоторой оглядкой на легкость сопровождения). Как бы не был прекрасен любой конкретный язык - он бесполезен в отрыве от библиотек, которые требуются для решения задач. Мне нужен очень весомый повод чтобы тратить время на создание переходников и тем более - на написание аналога с нуля на нужном языке.
Выступлю защитником Нима. Согласен, что это высказывание, вероятно, скорее звучит как агитка, очень часто, и не только автор этого языка, желают видеть своё детище единственным. Про звучание согласен, однако, если посмотреть на Nim, то он имеет FFI со многими языками гораздо более дружественную чем можно было бы ожидать после такого высказывания:
C - тут вообще без вопросов, так как Nim компилируется через него
JS - аналогично - Nim компилируется и в него
python - есть отличный nimpy
Собственно, но это конечно мой опыт, "тратить время на сздание переходников" тут приходится гораздо меньше чем во многих других языках. Но, с негативной оценкой этого высказывания согласен
А что там с идентификаторами, всё такое же странное правило, когда например идентификатор notin равен идентификатору notIn и это тоже самое что и NOT_IN? Очень оттолкнуло в своё время.
notin = notIn = NOT_IN
https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
Более того!
let Variable: int = 123
echo V_A_R_I_A_B_L_E
> 123Это, конечно, шутка, так делать не надо. (хотя это валидный код)
А если серьёзно, то это вовсе не баг, а фича и осознанное решение. Если вам интересно, в unifficial faq есть объяснения позиции о регистрах/подчёркиваниях. Честное слово, первая реакция на этот факт у меня была такая же как и у вас, но, попользовавшись языком, я теперь склонен скорее согласиться с faq'ом.
Поскольку мало кто пойдёт по ссылке, то чтобы не быть голословным, суть там примерно такая:
Делать разным только регистр — это плохой стиль, лучше сделать разными имена, чтобы было понятно о чём речь (в вашем примере различия между
notin=notIn=NOT_INсовершенно неочевидны).В принципе, нечувствительность обычно считается более дружественной пользователю, как например в файловых системах, конфигах и языках программирования (тут, наверное, должно быть «некоторых» или «даже», но следующий пункт объясняет что имеется ввиду).
Есть много примеров ЯП, где так же: Lisp, Basic, Pascal, Ada, Eiffel, Fortran. На Ada писали ПО для электростанций и самолётов и никто от этого не умер, значит человечеству от этого решения ничего не грозит.
Не надо путать нечувствительность к регистру и консистентность регистров в коде (что хороший стиль). Второго проще достичь с нечувствительностью к регистру в языке и правильно настроенной IDE
Это предотвращает ошибки. Когда код очень большой, уже сложно вспомнить как именно вы назвали сущность, и если язык к регистру нечувствителен, вы просто пишете его как привыкли и не боитесь, что промахнётесь.
Моё понимание: данная фича сделана для сторонних модулей включая FFI в другие языки. При этом и сам Nim Style Guide и большинсво модулей придерживаются camelCase
Тут, конечно, есть заигрывание в «должен остаться только один», но вообще имеется ввиду как раз то, что если вы выбираете Nim, то вы можете использовать его в любой задаче. (При этом если есть важная библиотека, то никто вам не мешает ffi пробросить, это делается практически по щелчку)
если вы выбираете Nim, то вы можете использовать его в любой задаче
Для меня первична задача, а не инструмент.
Допустим, надо обработать данные в формате csv. Если это однократная задача - в первую очередь я подумаю, нельзя ли сделать это в Excel. Если нет, и обработка достаточно проста - я, вероятно, воспользуюсь AWK. Если требуется сложная обработка и данные не слишком велики - я воспользуюсь R, одной строчкой прочитаю данные, и буду тратить время на решение задачи, а не на написание csv-парсера или переходника. И лишь в крайнем случае я буду пытаться обрабатывать csv файлы на C++. Как-то так.
Всё так. Но к слову сказать, в Nim есть csv парсер в стандартной библиотеке, его не надо писать.
И работа с ним ни на йоту не сложнее, чем с аналогичным в питоне, например.
Парсер в стандартной библиотеке
И что? Это какое-то супер преимущество? У меня точно так же может быть задача разбора не csv, а xlsx поколоночно. Ну, ничего страшного, что не будет в стандартной библиотеке этого модуля, главное, чтобы он был легко доступен и достаточно качественный. В том же python кажется два или три модуля для такой Задачи легко найти
Да нет же, просто вы написали, что будете писать парсер на C++ для csv в крайнем случае, и здесь, под этой статьёй, создаётся впечатление, что это имеет отношение к Nim'у.
Мне бы вот не пришло в голову брать Excel, для меня питон в этой задаче был бы образцом простоты, и Nim это сравнение легко выдерживает.
Для него (питона), безусловно, написано в 10 раз больше библиотек и они в 10 раз более проработаны, тут не поспоришь.
Но, опять же к слову, библиотека для разбора xlsx под Nim тоже есть и легко находится (правда пока WIP, но уже 0.4.5). Если верить описанию в репозитории, чтобы вывести содержимое xlsx файла надо 5 строчек, включая импорт и echo
то не я писал, а коллега lea
Всегда бесило вот такое навязывание единственного, расово верного инструмента.Ну так это естественная борьба заинтересованных сторон: разработчики всегда за узкоспециализированный ЯП в проекте (обычно он новый — можно развлечься, легче работать со специализированным инструментом), и бизнес всегда за универсализацию (легче находить недорогих сотрудников).
Ним - очень интересный как проект. Но работать на нём с проектом на больше чем 100 строчек - боль. Вот этот весь короткий синтаксис и улучшайзеры в духе ну ты можешь написать f(a) но можешь и f a, но если ты результат передаешь в другую функцию ты должен b(f(a)) а b f a вызовет хз какое поведение бесит.
Js ненавидят за допущения и вседозволеность, но js динамический. Теперь вот сделали статический язык с допущениями и вседозволенностью. Мб народу и зайдёт, конечно, но вот лично я никак не готов на этом программировать.
Коллеги, а уже существует русскоязычное онлайн-сообщество адептов и интересующихся Nim?
Дзен Nim