Представлен (https://nim-lang.org/blog/2018/03/01/version-0180-released.h... значительный релиз языка системного программирования Nim 0.18.0 (https://nim-lang.org). Язык использует (https://ru.wikipedia.org/wiki/Nim) статическую типизацию и создан с оглядкой на Pascal, C++, Python и Lisp. Код проекта поставляется (https://github.com/nim-lang/Nim) под лицензией MIT.
Исходный код на языке Nim компилируется в представление на C, C++ или JavaScript. В дальнейшем полученный C/C++ код компилируется в исполняемый файл при помощи любого доступного компилятора (clang, gcc, icc, Visual C++), что позволяет добиться производительности близкой к Си, если не учитывать затраты на выполнение сборщика мусора.
По аналогии с Python в Nim в качестве разделителей блоков применяются отступы. Регистр написания символов в идентификаторах не учитывается. Поддерживаются средства метапрограммирования (https://ru.wikipedia.org/wiki/%D0%9C%D0%... и возможности для создания предметно-ориентированных языков (DSL).
В новом выпуске отмечается ряд существенных новшеств и изменений, связанных с проведением чистки стандартной библиотеки перед релизом 1.0. Также внесена большая порция изменений, нарушающих обратную совместимость. Оператор индексирования "[]" теперь выдаёт ошибку, если запрошенный диапазон выходит за границы строки, вместо выдачи подпадающий под запрос части строки (например, var myString = "hello world"; myString[6 .. 45] теперь инициирует исключение IndexError). Также изменена логика обработки коллекций оператором "$" и прекращено приведение массивов array[x, char] к типу cstring. Спецсимвол "\n" теперь выводит только код перевода строки без кода возврата каретки.
Среди новшеств:
- Добавлен модуль strformat, предоставляющий поддержку форматируемых строковых литералов, позволяющих определить строку, содержащую подстановки (например let name = "Fred"; doAssert fmt"My name is {name}."), в стиле "f"-строк Python 3.6.
- В генератор документации добавлен макрос runnableExamples, позволяющий протестировать работу приводимых примеров кода.
- Добавлен новый макрос mapLiterals, упрощающий создание массивов и последовательностей (например, "let x = mapLiterals([12, 34, 15, 1], uint32)").
- Изменён алгоритм управления памятью. Новый алгоритм TLSF позволяет снизить фрагментацию памяти, ценой усложнения операций alloc и dealloc;- Серия изменений в модулях для асинхронного ввода/вывода. Представлена унифицированная реализация asyncdispatch и новая процедура getIoHandler, возвращающая дескриптор ввода/вывода или epoll/kqueue. В модуле asyncjs появилась новая реализация async await для бэкенда JavaScript;
- Пакетный менеджер Nimble обновлён до версии 0.8.10, в которой появилась возможность размещения нескольких пакетов Nimble в одном репозитории Git или Hg;
- Из stdlib в обособленные пакеты Nimble переведены библиотеки gentabs, libuv, polynumeric, pdcurses, romans, libsvm и joyent_http_parser. Объявлены устаревшими basic2d и basic3d, вместо которых следует использовать такие пакеты, как glm, arraymancer и neo.
URL: https://nim-lang.org/blog/2018/03/01/version-0180-released.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=48186
> По аналогии с Python в Nim в качестве разделителей блоков применяются отступы.Зачем? Даже Гвидо признал что это было не лучшей идеей.
а можно ссылку на это утверждение Гвидо?
http://www.yaml.org/faq.html> Tabs have been outlawed since they are treated differently by different editors and tools. And since indentation is so critical to proper interpretation of YAML, this issue is just too tricky to even attempt. Indeed Guido van Rossum of Python has acknowledged that allowing TABs in Python source is a headache for many people and that were he to design Python again, he would forbid them.
Но, возможно, он бы стал требовать просто по 4 пробела. Или нет, по 5. Хотя нет, по 3 было бы лучше всего - ведь это так сильно меняет программу, сколько пробелов в каждой строке ставить.
p.s. Я до сих пор не могу найти лучшего кандидата на первое место в списке "самые идиотские решения в ЯП", чем задание синтаксической конструкции отступами.
Вы прочитали то, что процитировали? Он не против отступов, он против табуляций. Чтобы творческие личности могли в один отступ два пробела вставить, а в другой шесть. Пробелы хороши в функциональных языках - там всё равно нет отступов, лишь выравнивание. Но в императивных языках запрещать надо, скорее, пробелы, чем табуляции.
Было бы логичней, как раз, в начале строки пользоваться табуляцией, а после первого непробельного символа разрешить только пробел. Один таб -один отступить и форматирование не разваливается при разном размере таба.
> Было бы логичней, как раз, в начале строки пользоваться табуляцией, а после
> первого непробельного символа разрешить только пробел.А не логичней было бы сперва ознакомиться с мат.частью, а уж потом рассуждать на тему "как правильнее"?
Обычно под «форматированием пробелами» понимаются только пробелы в начале строки. После первого непробельного символа - хоть трава не расти.>Один таб -один отступить и форматирование не разваливается при разном размере таба.
Разный размер таба в одном файле?
>Обычно под «форматированием пробелами» понимаются только пробелы в начале строки.Это и есть глупость
>После первого непробельного символа - хоть трава не расти.
Если после непробельных символов используется таб, то форматирование разъедется при открытии файла в другом редакторе с другим размером таба.
>Разный размер таба в одном файле?
В разных редакторах у разных пользователей
>>Обычно под «форматированием пробелами» понимаются только пробелы в начале строки.
> Это и есть глупостьНу, если авторитет опеннета так считает.
>>После первого непробельного символа - хоть трава не расти.
> Если после непробельных символов используется таб, то форматирование разъедется при открытии
> файла в другом редакторе с другим размером таба.Самому компилятору\интерпретатору это до одного места. Т.е. никакого насилия над Свободой Форматирования, о чем тут так пекутся некоторые, в этом случаене будет. А превращаться в плохо читаемую кашу оно будет в других ЯП точно так же.
>>Разный размер таба в одном файле?
> В разных редакторах у разных пользователейИменно отступы табами - не развалятся. Если вперемежку с отступами и прочим, тогда да, будет винегрет. Но зато теоретически есть полная Свобода Форматирования! Нет?
> Именно отступы табами - не развалятся. Если вперемежку с пробелами и прочим,
> тогда да, будет винегрет. Но зато теоретически есть полная Свобода Форматирования!
> Нет?fix.
То есть кроме отступов, табуляций и пробелов вас двоих ни чего не беспокоит в Nim? :-)
> Было бы логичней, как раз, в начале строки пользоваться табуляцией, а после
> первого непробельного символа разрешить только пробел. Один таб -один отступить и
> форматирование не разваливается при разном размере таба.Хорошо, что не все программисты школьники-дегенераты, и поэтому пользуются пробелами.
К отступам и пробелам чувствительна СКВ, поэтому, чтобы не париться с мержами конфликтов, я бы рекомендовал пользоваться автовыравнием, которое заточено под корпоративный стандарт.Зачем вообще париться над пробелами, если можно просто нажать "выровняйся всё само"?
Меньше творчества в коде => меньше конфликтов => проще жизнь.
> Хорошо, что не все программисты школьники-дегенераты, и поэтому пользуются пробелами.Как раз пробелами пользуются только те, кто не понимает, что такое отступ. "Я тут накопипастил со стека и у меня код разъехался. Поэтому я больше не буду пользоваться табуляциями, а некорректное форматирование буду пробелом добивать до того, от чего глаза не вытекают."
> Хорошо, что [...] пользуются пробелами.Можете привести пару (а лучше больше) объективных уважительных причин использовать пробелы в отступах вместо табуляций, пожалуйста?
> Хорошо, что не все программисты школьники-дегенераты, и поэтому пользуются пробелами.Дегенераты как раз пользуются пробелами в начале строки
>Дегенераты как раз пользуются пробелами в начале строкиДегенераты вообще не пользуются форматированием кода, ни табуляциями, ни пробелами. А все остальные могут воспользоваться средствами автоформатирования
Гвидо против табуляции, и правильно. Все осходники, использующие табуляцию, рано или поздно (на практике очень рано) начинают выглядеть как гaвно. Первое, что я делаю в не моем проекте, это заменяю все табы на пробелы. Только после этого с исходниками можно нормально работать. Разрабы, которые использовали там табы, даже ничего не замечают, потому что тем, кто использует табы, обычно положить, что их исходники выглядят как полное гaвно.
> p.s. Я до сих пор не могу найти лучшего кандидата на первое место в списке "самые идиотские решения в ЯП", чем задание синтаксической конструкции отступами.Ты, наверно, до того как начал использовать питон, код не форматировал в принципе, вот сейчас и испытываешь боли, что заставляют это делать на уровне синтаксиса языка?
Не знаю, как он, но спасибо что решили за всех, как им форматировать
В Golang, так любимом ненавистниками Python, форматирование тоже принудительное. С фигурными скобками, но отформатировать как тебе хочется не выйдет.
> В Golang, так любимом ненавистниками Python, форматирование тоже принудительное. С фигурными скобками, но отформатировать как тебе хочется не выйдет.ЕМНИП оно принудительное только в паре мест, где нельзя перенести открывающую фигурную скобку на следующую строку. Связано это с парсингом, а не стилем. А так можно хоть однострочники писать:
package main;import "fmt";func main() {fmt.Println("Hello, world")}Другое дело, что в сообществе Go принято пропускать исходник через gofmt. Но к этому никто не принуждает, просто правило хорошего тона.
> Но, возможно, он бы стал требовать просто по 4 пробела. Или нет, по 5. Хотя нет, по 3Оптимално по 2 ящетаю. Серьёзно.
Вообще уверен он имел вииду именно это. Я тоже поначалу плевался на эту идею, но потом мне стало очевидно, что для языка программирования (YAML - язык сериализации данных, а не программирования, так что там другая история) это оптимально ибо отступы всё-равно все всегда ставят и фигурные скобочки как и обязательные точки с запятыми в конце строк в C#-подобных языках - бессмысленный балласт.
На деле Python используется ОЧЕНЬ широко и никто особо не переживает по поводу этих отступов, так что всё в порядке. Некоторые небольшие проблем ощущаются только в момент копипастинга кода и те PyCharm решает за секунду.
>> Indeed Guido van Rossum of Python has acknowledged that allowing TABs in Python source is a headache for many people and that were he to design Python again, he would forbid them.https://nim-lang.org/docs/manual.html
> Indentation consists only of spaces; tabulators are not allowed.Все верно сделанно.
> Но, возможно, он бы стал требовать просто по 4 пробела. Или нет, по 5. Хотя нет, по 3 было бы лучше всего - ведь это так сильно меняет программу, сколько пробелов в каждой строке ставить.
Хоть 1, хоть 10. Главное, не поддаваться порывам творческой натуры и не менять количество пробелов в одном блоке.
Кстати, обычно даже довольно простые текстовые редакторы вполне настраиваются на автозамену нажатия таба на определенное количество пробелов.
>оглядкой на PascalЧто там от паскаля? Да и оберон уже давно есть.
Ну и пиши на своём Обероне. Много напишешь?
Имелось ввиду зачем ориентироваться на паскаль если можно было вдохновляться тем же обероном.
> позволяет добиться производительности близкой к Си, если не учитывать затраты на выполнение сборщика мусораа если ещё какие-нибудь не учитывать, то даже быстрее получится
а если вообще никакие не учитывать, то все расчёты будут мгновенными
Ну GC там и вправду мало жрущий. К тому же легко отключается. Хоть полностью, хоть по частям.
>> позволяет добиться производительности близкой к Си, если не учитывать затраты на выполнение сборщика мусора
> а если ещё какие-нибудь не учитывать, то даже быстрее получитсяХочешь - не учитывай, никто не мешает:
https://nim-lang.org/docs/manual.html
> Nim distinguishes between traced and untraced references. Untraced references are also called
> pointers. Traced references point to objects of a garbage collected heap, untraced references
> point to manually allocated objects or to objects somewhere else in memory.
>> позволяет добиться производительности близкой к Си, если не учитывать затраты на выполнение сборщика мусора
>а если ещё какие-нибудь не учитывать, то даже быстрее получитсяНу так в случае с Java так и получается :)
> Исходный код на языке Nim компилируется в представление на C, C++ или JavaScript. В дальнейшем полученный C/C++ код компилируется в исполняемый файл при помощи любого доступного компилятораЧто за блажь такая — всё усложнять дважды делать одну работу? В чём фишка?
обычное дело в эти дни, вы видимо имеете очень смутное представление об устройстве современных компиляторов
Почему только современных? И C++ изначально в C транслировался.
А потом как смогли - стали делать нормальные компиляторы. И по сей день продолжают.
> обычное дело в эти дни, вы видимо имеете очень смутное представление об
> устройстве современных компиляторовАнонимы опеннета, видимо, патологически неспособны понять написанное, а отсутствующее понимание компенсируют многозначительным гулом голосов из своей головы.
Ещё раз вопрос к залу: зачем писать на каком-то третьем языке, чтобы затем это несколько раз последовательно транслировать в нижележащие уровни? У современных кодеров совсем уже нет мозгов писать сразу на каком-то одном языке, что надо придумывать по несколько надстроек друг над другом?
> Анонимы опеннета, видимо, патологически неспособны понять написанное, а отсутствующее понимание компенсируют многозначительным гулом голосов из своей головы.
> Ещё раз вопрос к залу: зачем писать на каком-то языке, чтобы затем это несколько раз последовательно транслировать в нижележащие уровни? У современных кодеров совсем уже нет мозгов писать сразу в машинных кодах, что надо придумывать по несколько надстроек друг над другом?Fixed*
Просто у Nim дико маленокое комьюнити и написать полноценный фасад к какому-нибудь LLVM они не осилили
> Просто у Nim дико маленокое комьюнити и написать полноценный фасад к какому-нибудь
> LLVM они не осилилиОдин чувак осилил, но Araq (создатель языка) сказал, что он добавит LLVM в главный репозиторий только если LLVM бекенд предоставит какие-то преимущества над C/C++.
> Один чувак осилил, но Araq (создатель языка) сказал, что он добавит LLVM
> в главный репозиторий только если LLVM бекенд предоставит какие-то преимущества над C/C++.В чем-то он прав – обратная совместимость в LLVM довольно регулярно ломается, в отличие от.
И поэтому просто портировать мало, нужно еще и поддерживать.
Так что понятно, что (максимум "полтора", если мне не сильно изменяет память) разработчика/автора дополнительный "чемодан без ручки" скорее всего не особо вдохновляет.
Аналогично, зачем писать на любом сколько-нибудь высокоуровневом языке, если все можно написать в машинных кодах? Или в байткоде llvm если нужна переносимость.
Зачем транслировать язык X в язык Y? Например, затем, что реализация Y есть под платформу P и она популярна, при этом язык X предоставляет удобные абстрации для предметной области A и/или задачи T, которую надо решать.
Если задачу T можно решить на языке Y, это еще не значит, что ее удобно решать на этом языке, а при решении не придется написать существенное количество велосипедов.
Не стоит метать бисер перед Anonymoustus. Он объявился в новостях недавно, а уже успел себя зарекомендовать.
Компиляторы с/cpp есть практически под все известные платформы. Поэтому авторы ограничили свои усилия работой над самим ЯП и транслятором для него. Вполне разумно.
Ага, и препроцессоры на C не нужны. Ъ-кодеры обходятся без них.
>>Исходный код на языке Nim компилируется в представление на C, C++ или JavaScript. В дальнейшем
>Что за блажь такая — всё усложнять дважды делать одну работу? В чём фишка?Так Си и есть высокоуровневый ассемблер.
Есть же Crystal. Прекрасный руби-подобный синтаксис, быстрый....
Have a syntax similar to Ruby (but compatibility with it is not a goal)
Statically type-checked but without having to specify the type of variables or method arguments.
Be able to call C code by writing bindings to it in Crystal.
Have compile-time evaluation and generation of code, to avoid boilerplate code.
Compile to efficient native code.
Наркомания какая-то ваш кристал, лучше уж D
А может проще сразу писать на C/C++
> А может проще сразу писать на C/C++Так они тоже транслируются.
Поэтому для любителей истинной простоты есть hex-редакторы.
В них и машкод и микрокод под задачу написать можно.
Так hex-код тоже транслируется в нули и единицы. А вообще проще всего взять батарейку, две иголки и сраду подавать нужное напряжение в нужных участках материнской платы.
"язык системного программирования" и "сборщик мусора" -- взаимноисключающие параграфы
Давно нет. Разве что вы под "системным" понимаете исключительно ядро и драйверы. Впрочем, язык всё равно пришибленный.
> "язык системного программирования" и "сборщик мусора" -- взаимноисключающие параграфыТ.е. ЯП, в которых есть подключаемый сборщик мусора -- не системные?
http://www.hboehm.info/gc/
A garbage collector for C and C++
Чукча не видит разницу между покдлючаемым гц и по умолчанию.
> Чукча не видит разницу между покдлючаемым гц и по умолчанию.Чего - "по умолчанию", о великий знаток?
Или ты пользуешься обычными указателями и дергаешь alloc/dealloc ручками или используешь указатель на GC-объект.https://nim-lang.org/docs/manual.html
> Nim distinguishes between traced and untraced references.
> Traced references point to objects of a garbage collected heap, untraced references
> point to manually allocated objects or to objects somewhere else in memory.
> Traced references are declared with the ref keyword, untraced references are declared with the ptr keyword. In general, a ptr T is implicitly convertible to the pointer type.Интересно, какие принципы и обеты не позволяют экспертам перед комментированием даже поверхностно ознакомиться с темой?
> взаимноисключающиеКак ни загляну в комменты — обязательно узнаю новое слово. Что означает?
только BASIC из zx spectrum 48 самый понятный и запоминающийся