| |
| 2.3, Зщз (?), 00:21, 11/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Логическая цепочка: продакшен = энтерпрайз = текучка = новички не знают nim.
Сможете сами сделать выводы?
| | |
| |
| 3.18, Лапчатый девляпс бубунтёнак (?), 09:47, 11/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Пытаюсь сделать выводы:
- В ним - почти все мы - новички, язык не попсовый, и это нормально. Дайте юзкейс, и я его освою. На го у меня ушло пару недель, например.
- энтерпрайз = текучка - прямой зависимости нет, но в большинстве нынешних шараг - таки текучка(когда я арботал в сиске, то даже выполнял роль HR, собеседуя будущих неу-дачников, в том числе и на своё место). Там же, где я арботаю - пока-что нет текучки.
| | |
|
|
| 1.2, Андрей (??), 00:07, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– | |
В Debian, похоже, фанат языка опакечивает, т.к. версия 0.20 уже 3 дня как доступна:
> nim (0.20.0-1) unstable; urgency=medium
>
> * New upstream release
>
> -- Federico Ceratto <federico@debian.org> Fri, 07 Jun 2019 10:37:13 +0100 | | |
| 1.4, Аноним (4), 00:23, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> "Not" теперь всегда является унарным оператором, т.е. выражения вида "assert(not a)" теперь недопустимы и допускается только указание "assert not a";
Как из первого следует второе? Поясните.
| | |
| |
| 2.6, Аноним (6), 00:43, 11/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Более того, почему в первом варианте not не считается унарным?
В общем, очередной язык, чья главная фича - это пРиКоЛьНыЙ))) синтаксис
| | |
| 2.8, Junior frontend developer (?), 01:37, 11/06/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Видимо неявный приоритет операторов. Скорее всего имелось ввиду что скобки теперь опциональны.
Согласен с оратором выше, язык довольно безыдейный, лучше брать мейнстримный язык или Rust.
| | |
| |
| 3.9, Sw00p aka Jerom (?), 02:29, 11/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Скорее всего имелось ввиду что скобки теперь опциональны.
и где тут логика? то у них отрицание "не унарное", а теперь скобки не обязательны? так скобки на то и нужны, чтобы задать явно приоритет вычислений при равных приоритетах операторов.
| | |
| |
| 4.37, Ordu (ok), 19:01, 11/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Я не знаю как там было дело, но я возился с парсерами и поэтому предположу. Строчка 'assert not a' по идее, должна парсится в AST вида assert(not(a)). В смысле применение оператора not к a, после чего результат засовывается аргументом к assert. Но у них получалось не assert(not(a)), а not(assert, a), после чего понятно, компилятору становилось плохо.
Теперь, когда они исправили парсер, скобки стали опциональны, потому что парсер даже без них строит корректное AST.
| | |
| |
| 5.42, Sw00p aka Jerom (?), 22:10, 11/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Теперь, когда они исправили парсер, скобки стали опциональны, потому что парсер даже
> без них строит корректное AST.
в статье написано, "т.е. теперь допускаются выражения вида "assert not a", которые ранее приводили к ошибке;"
то есть, раньше такое выражение без скобок трактовалось как? вы предположили как not(assert(a)), но вопрос в том, что если даже и так "assert not a", то левосторонний парсер должен был понять как assert(not(a)), не так разве?
""Not" теперь всегда является унарным оператором," - вот это предложение вообще жесть, из той же википедии
"Побитовое отрицание (или побитовое НЕ, или дополнение) — это унарная операция", она что у них была не унарной? где логика?
пс: 1.7, Аноним отметил, что это неточность перевода.
| | |
| |
| 6.45, Ordu (ok), 23:12, 11/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
>> Теперь, когда они исправили парсер, скобки стали опциональны, потому что парсер даже
>> без них строит корректное AST.
> в статье написано, "т.е. теперь допускаются выражения вида "assert not a", которые
> ранее приводили к ошибке;"
> то есть, раньше такое выражение без скобок трактовалось как? вы предположили как
> not(assert(a)), но вопрос в том, что если даже и так "assert
> not a", то левосторонний парсер должен был понять как assert(not(a)),
> не так разве?
Это смотря как понимать слово "должен" в этом контексте. Он должен был в смысле "ought", и исправление парсера указывает на то, что действительно новое поведение правильно, оно должное поведение (хотя в русском можно было бы сказать "парсеру следовало бы понять", вы сказали не так, то есть наверное не этот смысл имели в виду?). Но вообще парсер никому ничем не обязан, и он может спокойно падать с сегфолтом, забивая на все попытки программиста убедить его продолжать работу стоя.
| | |
| |
| 7.47, Sw00p aka Jerom (?), 01:27, 12/06/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Но вообще парсер никому ничем не обязан
как так? хотите сказать, что он до сих пор не знал что такое функция как аргумент функции?
| | |
|
|
| 5.43, Sw00p aka Jerom (?), 22:36, 11/06/2019 [^] [^^] [^^^] [ответить]
| +/– | |
not у них - логическое отрицание, bitnot битовое, суть не меняется - всегда была унарной. А у них только стала судя из статьи :)
в документации proc 'not'(x: bool): bool {.magic: "Not", noSideEffect.} - один аргумент, - унарная.
| | |
|
|
|
|
| 1.7, Аноним (7), 00:51, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
Это просто странный перевод. Вот оригинал
>let a = false
>
># v0.19:
>assert not a # Error: type mismatch: got <proc (cond: untyped, msg: >string): typed, bool>
>assert(not a) # workaround
># v0.20:
>assert not a | | |
| 1.13, Аноним (13), 07:48, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Разлечение не более. Без отладчика жизни нет. Проще уже c++ осилить и жить припеваючи.
| | |
| |
| 2.14, Аноним (14), 08:52, 11/06/2019 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> Без отладчика жизни нет.
А что, gdb не работает? Если nim транслируется в C, для этого транслятору всего-то и надо, что директивы #line расставить.
| | |
| |
| 3.22, Аноним (13), 10:34, 11/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Привет, писатель helloworldow, тебе может быть нормально писать на одном языке, а отлаживать на другом, но нормальным людям надо работать
| | |
| |
| 4.28, Аноним84701 (ok), 13:15, 11/06/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
 > Привет, писатель helloworldow, тебе может быть нормально писать на одном языке, а
> отлаживать на другом, но нормальным людям надо работать
Привет Экспертам Опеннета -- Знатокам обсуждаемой темы (и принципов работы GDB)!
% cat hello.nim
let
x:int = 5
y:string = "hello"
var
z:int = x + 1337
z += z;
echo y, "World!", z
% nim c --debugger:native hello.nim
% gdb hello
>>> b hello.nim:7
Breakpoint 1 at 0x2126b6: file /tmp/nim/hello.nim, line 7.
─── Source ──────────────────────────────────────────────────────────────────────────────
1 let
2 x:int = 5
3 y:string = "hello"
4 var
5 z:int = x + 1337
6
7 z += z;
8 echo y, "World!", z
>>> p z_
$1 = 1342
>>> n
>>> p z_
$2 = 2684
>>> frame
#0 NimMainModule () at /tmp/nim/hello.nim:8
8 echo y, "World!", z
| | |
| 4.30, Аноним (30), 13:37, 11/06/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> нормальным людям надо работать
Если тебе некогда разбираться, как работает дебаггер, так и скажи, а не пытайся умничать.
Для очень занятых: gdb с nim работает, проверил. Но, что предсказуемо, не умеет показывать значения элементов массивов, последовательностей и т. п.
| | |
| |
| 5.31, Аноним84701 (ok), 13:52, 11/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> gdb с nim работает, проверил. Но, что предсказуемо, не
> умеет показывать значения элементов массивов, последовательностей и т. п.
В смысле?
var
5 z = [1,2,3,4,1337]
>>> p z_<tab>[4]
$4 = 1337
>>> p z_<tab>
$1 = {[0] = 1, [1] = 2, [2] = 3, [3] = 4, [4] = 1337}
Единственно, name mangling немного мешает.
| | |
| |
| 6.32, Аноним (30), 15:00, 11/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ну да, понятное дело, что если разобраться в манглинге, можно заставить работать. Я просто поленился препарировать сгенерированный код. Зато переменные не манглятся.
| | |
|
| 5.35, Аноним (13), 15:58, 11/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Мне хватило времени изучить C++, а но на извращения времени не хваатет
| | |
| |
| 6.44, Аноним (14), 23:11, 11/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Мне хватило времени изучить C++
Зачем обманываешь, а? C++ невозможно изучить за конечное время.
| | |
|
|
|
|
|
| 1.16, Wilem (?), 09:03, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– | |
> Pascal, C++, Python и Lisp
Всё то, что надо было выкинуть и использовать только как примеры «как не надо делать».
Из питона взяли систему отступов — неудачную фичу, ломающую навигацию по коду, его читаемость и написание.
Из чего вывод один: автор языка не вполне понимает, что и зачем он делает. Ему просто прикольно.
| | |
| 1.19, Аноняшка (?), 10:19, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> использует статическую типизацию
на динамической писать и проще и быстрее, в разы, - да и порого вхождения сильно ниже
> и создан с оглядкой на Pascal, C++, Python и Lisp
а что общего у этих четырех (весьма достойных) языков программирования?
хипстер-смузи решил скрестить ужа с ежом?
> код на языке Nim компилируется в представление на C, C++ или JavaScript
что общего между С и JavaScript? (так и представил веб-макаку, гордо пишущую в резюме: "умею писать hello world на Nim и компилить его в JS, претендую на зарплату на 20% дороже"
> По аналогии с Python в Nim в качестве разделителей блоков применяются отступы\
ну почему, почему из Пихтона взяли худшее??
хотите легкости написания - делайте динамическую типизацию, отите качества - делайте С-подобный синтаксис....
> Код проекта поставляется под лицензией MIT.
Столлман ворчит неодобрительно и призывает громы небесные на Несвободных
| | |
| |
| 2.20, Аноним (20), 10:26, 11/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
наверно потому что статическая типизация как бы быстрее скомпилиреутся чем динамическая не? правда тогда можно и на си писать.
и чем всем так помешали отступы? тем, что заставляют писать аккуратнее?
| | |
| |
| 3.23, Аноним (6), 10:51, 11/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Представь, что вместо явных знаков "обгон запрещен"/"конец зоны запрещения обгона" придумали вот какую штуку: "если трасса, идущая с запада на восток, вдруг сместилась на 20 метров к северу, то на смещенном участке трассы обгонять запрещено".
| | |
| |
| 4.27, Аноним (20), 11:57, 11/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
ну да, это видимо у каждого по своему. не испытывал проблем с отступами. единственное, что - обратно возвращаться тяжело, опять же решаемо несколькими днями практики.
| | |
|
| 3.38, Ordu (ok), 19:20, 11/06/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> наверно потому что статическая типизация как бы быстрее скомпилиреутся чем динамическая не?
Не. Динамическую проще компилировать: не надо высчитывать типы выражений и сверять их с типами переменных куда результаты вычисления выражений складываются. Вот глянь на попытку запилить комбинаторы парсеров в rust[1], если ты пролистаешь вниз ближе к концу, ты найдёшь интересный поворот в сюжете[2], когда время компиляции улетело в бесконечность, и чтобы с этим справится, пришлось переходить к динамической типизации, жонглируя в рантайме ссылками на трейты, вместо ссылок на объекты конкретных типов.
Понятно, что это (то есть описание синтаксиса в системе типов, задавающее любому грамматически правильному выражению соответстующий тип) больше похоже на извращение, и в языках где невозможно создание рекурсивных типов, не будет возможность подобное сотворить и ситуация когда 200 строк кода компилируется десять минут не возникнет, но и тем не менее, суть остаётся той же: типизация -- это дополнительная работа компилятору.
[1] https://bodil.lol/parser-combinators/
[2] https://bodil.lol/parser-combinators/#so-close-now
| | |
|
| 2.21, frthrjt (?), 10:29, 11/06/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>Столлман ворчит
И пусть. GPL запрещает некоторые другие свободные лицензии совместно использовать. Из-за этого у ZFS проблемы были.
| | |
| 2.29, Аноним84701 (ok), 13:25, 11/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> код на языке Nim компилируется в представление на C, C++ или JavaScript
> что общего между С и JavaScript? (так и представил веб-макаку, гордо пишущую
Если вы не знаете, что такое бэкнэнд ЯП/компилятора, то возможно, не стоит пока и обзывать кого-то "веб-макакой"?
> ну почему, почему из Пихтона взяли худшее??
> отите качества - делайте С-подобный синтаксис....
Ну-ну
volatile const static signed long int* const restrict borsch = {(const volatile void*)0};
к-кааачеееествооо!
| | |
| 2.33, Аноним (30), 15:02, 11/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> на динамической писать и проще и быстрее, в разы, - да и порого вхождения сильно ниже
Зато ошибки потом вылавливать дольше на порядки.
| | |
| |
| 3.41, angra (ok), 21:58, 11/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Ну разве что пишутся килобайты кода, а потом сразу отдаются пользователям без каких-либо проверок на работоспобность и правят ошибки уже на основе баг репортов. У вас так работают?
Действительно трудноуловимые ошибки возникают в случае слабой типизации, которая вполне может сочетаться со статической.
| | |
| |
| 4.46, funny.falcon (?), 01:25, 12/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Питон ведь со строгой типизацией?
Давным давно одну либо пытался заюзать. Видимо, позвал метод, который разрабам давно не был нужен в их ежедневной работе. И в каких-то недрах либо вполне себе TypeError вылетел. Заглянул в сырую: очевидно, что раньше там из внутреннего метода одиночное значение возвращалось, и в месте падения ожидалось. Где разрабам нужно было, они поправили. А нужный мне метод оказался сиротинушкой.
Конечно, если бы у них были тесты на этот метод, они бы заметили. Но если бы была строгая типизация, они тоже бы заметили.
| | |
|
|
| 2.48, funny.falcon (?), 01:31, 12/06/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> на динамической писать и проще и быстрее, в разы, - да и порого вхождения сильно ниже
Проще писать если не нужно руками типы прописывать. Но динамическая типизация не единственный путь к такому счастью. Есть ещё автоматический вывод типов.
Правда, полный автоматический вывод часто приводит к росту времени компиляции. По-этому либо просят программиста хотя бы иногда типы вручную указывать, либо накладывают какие-нибудь ограничения на систему типов.
Но в целом, даже на убогом Go вывод типов экономит много ручной писанины. При этом, Go - это один из самых плохих примеров этой фичи. Есть много языков, где это реализовано элегантнее и приятнее для программиста.
| | |
| |
| 3.50, Аноним (14), 21:15, 12/06/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Есть много языков, где это реализовано элегантнее и приятнее для программиста.
Заинтриговал.
| | |
|
| 2.51, Junior frontend developer (?), 21:16, 12/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
>> и создан с оглядкой на Pascal, C++, Python и Lisp
> а что общего у этих четырех (весьма достойных) языков программирования?
> хипстер-смузи решил скрестить ужа с ежом?
Взял фичи из разных языков
>> код на языке Nim компилируется в представление на C, C++ или JavaScript
> что общего между С и JavaScript?
В оба языка актуально компилироваться (нативная и веб платформы соответственно)
| | |
|
| 1.36, Нанобот (ok), 17:49, 11/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 как-то слишком много внимания на опеннете языку с полтора пользователями. не то, чтобы я был против, просто непонятна причина
| | |
| |
| 2.52, Andrey Mitrofanov_N0 (?), 13:42, 13/06/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> как-то слишком много внимания на опеннете языку с полтора пользователями,
Как-то слишком много внимания вашему непонимаию -- аж целый каммент. Не то, чтобы я был против, но тут на опенете каждый первый не понимает каждой второй новости...
>не то,
> чтобы я был против, просто непонятна причина
... и ничего-ничего-ничего.
| | |
|
|
