Сомнительная версия.

Я предполагаю ещё, что дело в ffi. Если мы используем внешний C++ код, то, вероятно, лучше чтобы и Nim-ский код тоже транслировался в C++, чтобы те же исключения лучше перехватывать, например.

Кстати, заметил, что чем больше читаешь про Ним, тем понятнее становится, что по сложности он не уступает C++. Миллион флажков, миллион особенностей для каждого языка, в который будем транслировать. Похоже, что это язык для академиков, для любителей повозиться с настройками.

Кстати, заметил, что чем больше читаешь про Ним …

Все же меня больше устраивает C/C++.
Все что нужно для системной разработки в них имеется.

Новые языки программирования мне интересны лишь в вопросах, как реализована работа с памятью, объектами, … /архитектура вообщем/.

Это ГЛАВНОЕ!

Владимир

Ты или что-то путаешь или в глаза этот раст не видел. К паскалю он ближе всего, а не к Си. Только переусложнённому настолько, что C++ в сравнении с ним это просто образец гармонии и красоты.

а говорили – ада сложная (говорили в основном те, кто её в глаза не видел), лол :))

Все что нужно для системной разработки в них имеется.

Вот как устроена любая ОС?

Конечно имеется некая архитектура, которая содержит разные подсистемы, …

Вот для этого C и был создан. Для того, чтобы с использованием его можно было реализовать любую архитектуру.

А его пытаются применять для забивания гвоздей микроскопом.

Владимир

Новые языки программирования мне интересны лишь в вопросах, как реализована работа с памятью, объектами, … /архитектура вообщем/.

Да, разумеется. Для работы же годятся только языки проверенные временем. Nim рискованно использовать для разработки программ. На мой взгляд, разработчики взвалили на себя ношу, с которой не справятся. Одиночкам и маленьким командам лучше разрабатывать что-то более примитивное.

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

Nim рискованно использовать для разработки программ.

Может быть и так /не знаю/.

Владимир

про осмысление языков

Нет там ничего от паскаля, объявления переменных и даже внешний вид лайфтаймов взят прямиком из OCaml, на котором и была написана первая версия раста.

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

ну или через процедурные AST макросы.

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

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

и хороши языки в которых идея, миссия, концепция словно тезис. в десяток слов могут эти фичи сформулировать и как-то наглядно продемонстрировать.

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

«модель акторов с минимально разделяемой памятью» в том же pony.

концепция «для всего обо всё сам на себе, паки метапрог эдакий» – слишком общО, размыто и непонятно.

сложно осмыслить например какой-то лисп. какой он есть, каким он может быть. и нафига именно такой набор фич.

когда для осмысления по наглядным примерам готовых систем и их фичам требуется перечитать CLtL с AMOP + посмотреть лисп-машину, ну или посмотреть на смоллток с интерлиспом и medley.

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

опять же если про nim. ну вот PLOT лисп от David Moon симпатичен. тоже как бы питон и вроде лисп. правда кроме его генератора markdown->HTML+SVG примеров кода да и самой реализации языка толком и не видно.

Вот для этого C и был создан. Для того, чтобы с использованием его можно было реализовать любую архитектуру.

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

любую архитектуру можно реализовать на любом языке

Оно то так.
Но C как бы это сказать, имеет все необходимое для системной разработки и спроектирован был именно для системной разработки.

Владимир

Новые языки программирования мне интересны лишь в вопросах, как реализована работа с памятью, объектами, … /архитектура вообщем/.

архитектура чего?

я б это так сформулировал: в парадигмах, подходах, технологиях программирования есть понятие «first class object». это такое абстрактное высокоуровневое понятие языка (фича, возможность, парадигма вот.. модель мышления – мыслеформа, в общем) которое конкретизируется через систему типов в конкретную низкоуровневую реализацию.

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

вот например теорема относительности в тензорной форме. концептуальная красота – слева математика: геометрия, связность, топологические пространства. справа – физика: материя, энергия, е равно эмси квадрат и формула Умова.

вектор Умова кстати, тоже красивый.

формула Киргхоффа в комплекснозначном виде, например. повороты в кватернионах. общая теория поля в октанионах с седенионами.

эта умозрительная красота формул абстрактных first class объектов, фич, понятий. метаобъектного протокола кластера метапарадигм :) с какими-нибудь там композабельными макросами, аспектами и т.п.

полезна – упрощает мышление и экономит сложности выкладок. и упрощает конструирование, то есть практически полезна, а не только умозрительно.

типа «критерий жизнеспособности архитектуры – красота. некрасивые самолёты не летают» :)

а так-то да, понятно. что на любом языке можно реализовать любой другой (и любую архитектуру).

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

архитектура чего?

Работы с данными.
К примеру в Python она «не очень» и результат «не очень».

Владимир

Все же меня больше устраиваЮт C и C++

пофиксил. Почему вы их через слэш пишите, не понимаю?

Почему вы их через слэш пишите, не понимаю?

А вы в google в поисковой строке введите C/C++ и увидите, что не я один такой.

Владимир

Загуглил «стадное чувство», все стало ясно.

Загуглил «стадное чувство», все стало ясно.

Да и мне пожалуй стало ясно … Просьба не вести со мной диалог /с своей стороны гарантирую/.

Владимир

Но C как бы это сказать, имеет все необходимое для системной разработки и спроектирован был именно для системной разработки.

C – это минимализм осмысления. переосмысления кучи фич, из которых взлетели не все сложного Multics. реализованного на сложной куче фич PL/I.

только повторно реализованное переосмысление почему-то на каком-то BCPL. (на самом деле, у них был TMG, на котором была реализация PL/I. типа ассемблера на awk. ну на ней и запилили свой клон BCPL, B).

далее из интерпретируемого бестипового CPL, BCPL, B. концептуальная дырка в указателях в (*void) прокралась. и все эти типизированные ссылки, зависимые типы, тайптеги и прочие лет 50 её пытаются заткнуть.

в этом смысле, неаккуратненько. и некрасиво.

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

например, свалка из API BSD/SysV -> необходимость появления POSIX.

свалка в ядре из 200+ системных вызовов.

понадобился целый plan9 чтобы понять как эту свалку можно разгрести. в файловый сервер/объектный сервер/сетевой сервер на протоколах P9FS, Styx.

и inferno + limbo + dis + kencc для реализации этой архитектуры.

которую потом в андройде опять ниасилили.

взяли linux ядро + boinc libc + жабу вместо limbo/kencc, dalvik вместо dis, нативный go с горутинами, каналами и интерфейсами ad-hoc вместо limbo с корутинами, каналами и немного другими интерфейсами :)

лишь бы «shared libraries considered harmful» заново не переписывать. в этот концептуально красивый файловый сервер на Styx.

вообще, такое ощущение, что в инферно оберон пытались повторно реализовывать. только почему-то на си. или лимбо.

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

а взяли заместо него какой-нибудь PL/I с исключениями или Аду с параллельными задачами, исключениями, параметрическими модулям, настраиваемым рантаймом и прагмами, спарком тем же.

и интересно понаблюдать – как эти высокоуровневые фичи зависят от встроенных фич системного языка реализации.

вот Multics был например написан на PL/I с исключениями. какой-нибудь Martens на Аде с тасками.

как эти фичи повлияли на конструируемость, композабельность, некую концептуальную целостность и красоту в архитектуре и её реализации – вот это всё?

(есть ощущение, что никак, лол. пока что вспоминается разве что MirageOS unikernel на окамле, где драйвера устройств это функторы и параметрические модули над функторами – композабельные в управление конфигурацией времени компиляции, CTFE парсер протокола TCP/IP из текстовой спецификации из RFC).

архитектура чего?

А вы погуглите и вам откроется много нового.

Владимир

К примеру в Python она «не очень» и результат «не очень».

в Python – GIL в реализации рантайма есть следствие некоторых концептуально непродуманных, некрасивых косяков на уровне идей и нехватки полезных метапарадигм :)

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

плюс на этом ещё и пишут задней ногой. результат предсказуемо «не очень».

Загуглил «стадное чувство», все стало ясно.

Идите к своим, в стойло.

Владимир

в Python – GIL в реализации рантайма есть следствие некоторых концептуально непродуманных, некрасивых косяков на уровне идей и нехватки полезных метапарадигм :)

Python упомянул лишь для ответа на ваш вопрос.
Кстати это отнюдь не значит, что язык плох.
Реализация, да - «не очень».

Владимир

ключевое слово proc? И это всё, чем nim похож на Паскаль?

ещё TObject из Borland Pascal/Delphi

М-да.
Обсудили Nim …

Изучаю

Хочу изучить с помощью Nim программирование. Немного знаком с разными языками, но вот захотелось писать на Nim. Прошу, накидайте задач различной сложности cli/gui для реализации на нём.

Как вариант для разогрева, напиасать САПР для проектирования подводных лодок. Nim классный язык, так что за пару месяцев управишься.

nim’у до pascal/delphi как раком до Пояса Койпера

открываешь Rosetta Code и пилишь задачу за задачей. потом еще и сравнить сможешь свою реализацию с той, что уже опубликована.

Розетты вполне достаточно, чтобы пощупать любой ЯП за вымя.

Начни лучше с языка программирования Ракудо.

А что это за язык? Гугл про Ракудо ничего не говорит

Посмотрел. На Common Lisp самые короткие решения получаются.

ну… субъективные впечатления субъективны, что тут скажешь )

наверное можно как-то автоматизировать подсчет объема кода. просто просуммировать по всем задачам, например, и вывести среднее. или еще как нибудь. не знаю заморачивался ли с этим хоть кто-нибудь.

насколько легко читать и понимать код - хз как тут оценивать объективно. наверное можно, но придется постараться.

навскидку - разные ЯП проявляют себя совершенно по-разному на разных задачах. где-то прям огонь, а где-то внезапно становятся невыразительными и косноязычными.

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

но походу это просто никому не нужно )

наверное можно как-то автоматизировать подсчет объема кода. просто просуммировать по всем задачам, например, и вывести среднее

Местами там попадаются «частичные» решения. Учитывать их будет нечестно. Опять же, «наиболее лаконичное», «идиоматическое» и «производительное» решение - это нередко три разных.

да, согласен.

к тому же ниоткуда не следует, что какой-то из этих трех настолько важен, что остальными можно пренебречь.

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

из этого сейчас есть разве что бенчи. пусть и в спорном, но хоть каком-то варианте.

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

кто запилит анализ «читабельности» (выразительности) будет герой и молодец )

Интересные у вас посты.

Владимир

Погуглите для начала embedded systems.

Владимир

А что это за язык? Гугл про Ракудо ничего не говорит

Овер энд овер энд лукинг ё харт ... Советую вбивать запрос в гугл на аглицком.

Владимир

а взяли заместо него какой-нибудь PL/I с исключениями или Аду с параллельными задачами, исключениями

Это невозможно. Просто в силу того, что PL/1 так и не был реализован, были лишь реализации части языка.

В Аду так же запихали столько, что создавать для неё компилятор не менее сложно, чем ОС. Но тут сразу вспоминается древний анекдот:

– Если ваша программа скомпилировалась с первого раза без сообщений об ошибках, сообщите об этом системному администратору. Он исправит ошибки в компиляторе.

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

Да и по другим параметрам у него не было тогда конкурентов. И ещё долго не появлялось.

Тогда как для Си надо было написать минимальную базовую часть, а остальное было написано на самом Си и компилировалось этой базой в полноценный компилятор на целевой архитектуре.

Не путай си с фортом.
А если серьезно то просто у си была хорошая переносимость (но хуже чем у того же форта) и при этом не мозголомный и высокоуровневый (по тем временам) язык.

https://github.com/nim-lang/Nim/wiki/Curated-Packages