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
Это предотвращает ошибки. Когда код очень большой, уже сложно вспомнить как именно вы назвали сущность, и если язык к регистру нечувствителен, вы просто пишете его как привыкли и не боитесь, что промахнётесь.
Да нет же, просто вы написали, что будете писать парсер на C++ для csv в крайнем случае, и здесь, под этой статьёй, создаётся впечатление, что это имеет отношение к Nim'у.
Мне бы вот не пришло в голову брать Excel, для меня питон в этой задаче был бы образцом простоты, и Nim это сравнение легко выдерживает.
Для него (питона), безусловно, написано в 10 раз больше библиотек и они в 10 раз более проработаны, тут не поспоришь.
Но, опять же к слову, библиотека для разбора xlsx под Nim тоже есть и легко находится (правда пока WIP, но уже 0.4.5). Если верить описанию в репозитории, чтобы вывести содержимое xlsx файла надо 5 строчек, включая импорт и echo
Тут, конечно, есть заигрывание в «должен остаться только один», но вообще имеется ввиду как раз то, что если вы выбираете Nim, то вы можете использовать его в любой задаче. (При этом если есть важная библиотека, то никто вам не мешает ffi пробросить, это делается практически по щелчку)
А ещё ним, несмотря на всё что в нём есть, производит ощущение цельности! И, может быть, это как раз благодаря небольшой команде (он там, всё-таки, не один, если быть честными)
По управлению памятью, кстати, кажется, тут ещё ссылка на эту статью будет уместна: Введение в ARC/ORC в Nim
да, там много флуда, но если что спросить, обычно помогают
есть чат в тг ru.nim.talks, там как раз и адепты, и интересующиеся, но не сказать, что он очень большой
А есть ли в отчёте количество человек, севших за лайки/посты в 2021?
Более того!
Это, конечно, шутка, так делать не надо. (хотя это валидный код)
А если серьёзно, то это вовсе не баг, а фича и осознанное решение. Если вам интересно, в unifficial faq есть объяснения позиции о регистрах/подчёркиваниях. Честное слово, первая реакция на этот факт у меня была такая же как и у вас, но, попользовавшись языком, я теперь склонен скорее согласиться с faq'ом.
Поскольку мало кто пойдёт по ссылке, то чтобы не быть голословным, суть там примерно такая:
Делать разным только регистр — это плохой стиль, лучше сделать разными имена, чтобы было понятно о чём речь (в вашем примере различия между
notin=notIn=NOT_INсовершенно неочевидны).В принципе, нечувствительность обычно считается более дружественной пользователю, как например в файловых системах, конфигах и языках программирования (тут, наверное, должно быть «некоторых» или «даже», но следующий пункт объясняет что имеется ввиду).
Есть много примеров ЯП, где так же: Lisp, Basic, Pascal, Ada, Eiffel, Fortran. На Ada писали ПО для электростанций и самолётов и никто от этого не умер, значит человечеству от этого решения ничего не грозит.
Не надо путать нечувствительность к регистру и консистентность регистров в коде (что хороший стиль). Второго проще достичь с нечувствительностью к регистру в языке и правильно настроенной IDE
Это предотвращает ошибки. Когда код очень большой, уже сложно вспомнить как именно вы назвали сущность, и если язык к регистру нечувствителен, вы просто пишете его как привыкли и не боитесь, что промахнётесь.
Приношу извенения, проглядел! Но сути ответа не меняет
Да нет же, просто вы написали, что будете писать парсер на C++ для csv в крайнем случае, и здесь, под этой статьёй, создаётся впечатление, что это имеет отношение к Nim'у.
Мне бы вот не пришло в голову брать Excel, для меня питон в этой задаче был бы образцом простоты, и Nim это сравнение легко выдерживает.
Для него (питона), безусловно, написано в 10 раз больше библиотек и они в 10 раз более проработаны, тут не поспоришь.
Но, опять же к слову, библиотека для разбора xlsx под Nim тоже есть и легко находится (правда пока WIP, но уже 0.4.5). Если верить описанию в репозитории, чтобы вывести содержимое xlsx файла надо 5 строчек, включая импорт и echo
Всё так. Но к слову сказать, в Nim есть csv парсер в стандартной библиотеке, его не надо писать.
И работа с ним ни на йоту не сложнее, чем с аналогичным в питоне, например.
Тут, конечно, есть заигрывание в «должен остаться только один», но вообще имеется ввиду как раз то, что если вы выбираете Nim, то вы можете использовать его в любой задаче. (При этом если есть важная библиотека, то никто вам не мешает ffi пробросить, это делается практически по щелчку)
А ещё ним, несмотря на всё что в нём есть, производит ощущение цельности! И, может быть, это как раз благодаря небольшой команде (он там, всё-таки, не один, если быть честными)
По управлению памятью, кстати, кажется, тут ещё ссылка на эту статью будет уместна:
Введение в ARC/ORC в Nim