Комментарии 24
Почему вы называете его — язык для системных/сетевых программистов?
В тексте не смог найти пояснений на этот счет?
Не кажется ли вам, что для сетевых программистов вход в мир Си и Ява очень трудный. Python в этом вопрос значительно проще и уже набрал хорошую популярность в среде сетевиков.
Как планируете развивать и строить комьюнити?
В тексте не смог найти пояснений на этот счет?
Не кажется ли вам, что для сетевых программистов вход в мир Си и Ява очень трудный. Python в этом вопрос значительно проще и уже набрал хорошую популярность в среде сетевиков.
Как планируете развивать и строить комьюнити?
Почему вы называете его — язык для системных/сетевых программистов?
В тексте не смог найти пояснений на этот счет?
Тут важно уточнить. Jancy — не язык системного программирования, а скриптовый язык для системного/сетевого программирования. По области применимости он целит не в Rust, а в Питон. А пояснения были. Он может быть удобен для системного/сетевого программирования (как минимум, в ряде сценариев) по следующим причинам:
- поддержка указателей на данные и адресной арифметики (самый лучший способ «гулять» по бинарным данным для анализа или генерации)
- ABI-совместимость с C/C++ бибилотеками (вызывать системные функции проще чем в любом другом скриптовом языке)
- Высокий уровень совместимости исходных кодов в с C (иногда можно вообще копипастить код и алгоритмы на С)
На самом деле, в языке есть и другие фишки, облегчающие написание асинхронных IO-приложений, но, пожалуй, в плане системных/сетевых скриптов эти три — основные.
Не кажется ли вам, что для сетевых программистов вход в мир Си и Ява очень трудный. Python в этом вопрос значительно проще и уже набрал хорошую популярность в среде сетевиков.
Это смотря откуда эти программисты пришли ;) Я всегда наоборот искал что-то си-подобное и подозреваю, что я в этом не одинок.
Python в этом вопрос значительно проще и уже набрал хорошую популярность в среде сетевиков.
Про простоту — см выше, си-подобные языки действительно имеют более высокий порог вхождения. Но это не столь релевантно, если человек УЖЕ приходит из си-мира. Jancy ориентируется именно на таких. А вот про популярность Питона у сетевиков — совершенно справедливо подмечено! Навряд ли я смогу это доказать, но думаю, что, одна из немаловажных причин этой популярности — это самый простой среди скриптовых языков вызов си из Питона. Так вот, Jancy идёт в этом направлении ещё дальше.
Как планируете развивать и строить комьюнити?
Это вопрос на миллион :) Как минимум — начать рассказывать, что вот-де есть такой скриптовый язык с указателями, поездить по конференциям, а в итоге мы, конечно, хотели бы найти увлечённых разработчиков, заинтересованных обсуждать, спорить, пробовать, а в идеале и присоединиться к работе над проектом.
НЛО прилетело и опубликовало эту надпись здесь
Да как минимум для поднятия своего скила.
Жаль что столько минусов — не думаю, что ваш коммент этого заслуживает. Я совершенно согласен, что языков понаваяно уже ого-го сколько, о чём и написал в самом первом абзаце. А то ли ещё будет! ;) Достаточность, однако, вопрос не такой однозначный. Всегда есть что улучшить, и всегда найдётся горячая голова, которая попробует это сделать. В нашем случае самый краткий ответ на вопрос «зачем?» — это создание скриптового языка с указателями и безопасной адресной арифметикой — такого пока не было.
Кстати, в Rust мы не метим. Думаю, что в будущем Rust (или что-то подобное) будет потихоньку теснить си на ниве системного программирования — это язык с по-настоящему прорывными концепциями в области управления памятью. У нас же — скриптовый язык. Мы метим в Питоны ;)
Кстати, в Rust мы не метим. Думаю, что в будущем Rust (или что-то подобное) будет потихоньку теснить си на ниве системного программирования — это язык с по-настоящему прорывными концепциями в области управления памятью. У нас же — скриптовый язык. Мы метим в Питоны ;)
Неплохая «обертка» над LLVM и пахнет действительно вкусно, по мне нехватает пока некоторых «прянностей» других скриптовых (например прямое substituation как функция, доступ в верхний scope, чтобы например создать свои «функции» для передачи body прямо в языке без биндинга, так же lambda expressions, что то типа closure, и т.д.), но оно придет с развитием… (а возможно просто я сразу не нашел).
И кое-что, естественно не нравится, например catch внутри scope try (типа прямой llvm метки?). Хотя о вкусах не спорят.
И кое-что, естественно не нравится, например catch внутри scope try (типа прямой llvm метки?). Хотя о вкусах не спорят.
Ах да, а есть где scm какой (или где на гитхабе и т.д. можно бы взглянуть)?
Исходники выложены на нашем сайте, про переехать на гитхаб — подумываем.
Да я видел, scm не совсем исходники…
Скорее всего, в определённый момент мы просто переедем на гитхаб. К сожалению, у меня нет опыта руководства опенсорсными проектами, поэтому имеются естественные опасения в связи с переездом и открытием проекта для редактирования сообществом. С другой стороны, как говорил в одном интервью автор D Волтер Брайт, одна из вещей, о которых он жалеет — это то, что не отдал D сообществу раньше :)
По поводу вкусностей, присутствующих в других скриптовых языках: лямбды и замыкания со временем обязательно появятся. Пока в качестве альтернативы настоящим замыканиям можно использовать частичное применение — в Jancy можно захватывать произвольные контекстные аргументы в момент создания указателя на функцию.
По поводу вкусностей, присутствующих в других скриптовых языках: лямбды и замыкания со временем обязательно появятся. Пока в качестве альтернативы настоящим замыканиям можно использовать частичное применение — в Jancy можно захватывать произвольные контекстные аргументы в момент создания указателя на функцию.
поэтому имеются естественные опасения в связи с переездом и открытием проекта для редактирования сообществом.А никто его не сможет редактировать, кроме тех людей кому вы это специально разрешили, изначально это может делать только owner. И это нормальная практика — контрибуция же от коммюнити идет через pull-request. Т.е. человек создает форк, правит там у себя что-то и отправляет запрос (pull-request) в вашу репо. А дальше уже вам решать.
Кроме того если у вас так и так git, то ваш локальный repo вообще не затрагивается если даже на гитхабе вообще все слетит или перепишется. (Оба репозитария равноценны) В вашем локальном репо, после fetch вы просто увидите что на гитхабе gh-origin ветки пропали, или были созданы новые. Ваше же все останется так и так, даже если будет fetch с выставленным prune (почистить удаленные ветки), в ref-log вы сможете найти и восстановить эти ветки еще некоторое время (пара недель если не ошибаюсь). Хотя обычно даже это не нужно, просто восстанавливается из другого репо, в котором они еще остались. Вплоть до полного пересоздания.
За свою долгую жизнь в опенсорсе я не слышал ни разу, чтобы кто-нибудь потерял чего-либо на git, fossil, hg, svn, cvs. Последние два с оговоркой, т.к. централизованы (если репо на сервере слетело — пиши пропало).
Спасибо за развёрнутый комментарий. Да, внутри компании в качестве version control мы используем git. Под опасениями я имел в виду скорее не то, что код на гитхабе пропадёт, а то, что я пока не до конца представляю себе, как заниматься управлением пулл-реквестов от совершенно незнакомых мне людей. Но ничего, разберёмся :)
Это все наверно хорошо, но вот долго думал где бы я это применил. И понял что нигде.
Насколько я люблю самописные языки, но с этим как-то не понял, в чем суть. Хочется больше примеров именно уникальных фич языка и сценариев, в которых он удобнее существующих аналогов.
Суть в близости нашего скриптового языка к си. Можно сказать, у нас скриптовый си с плюшками. Уникальных фич достаточно много (мы, на самом деле, подзатянули с «выходом в свет» с допиливанием уникальных фич)
И много нововведений по мелочи, как-то встроенная поддержка бигендианов, енумы для битовых флагов, указатели на функции с отложенным исполнением и другое. Здесь подробнее и с примерами: http://tibbo.com/jancy/features.html
- безопасная адресная арифметика
- встроенный генератор лексеров
- реактивное программирование на уровне языка
И много нововведений по мелочи, как-то встроенная поддержка бигендианов, енумы для битовых флагов, указатели на функции с отложенным исполнением и другое. Здесь подробнее и с примерами: http://tibbo.com/jancy/features.html
Неплохая задумка. Работать еще надо и, судя по всему, немало, но что-то в этом есть. Возможно, будет жить.
Псевдо-исключения, коды возврата и try/catch — это какая-то каша. И вообще, скриптовый язык с кодами возврата — это жуть. Вы-же LLVM используете. Не смогли выяснить как там генерировать код выбрасывающий и ловящий исключения? К тому же для x86-64 существует ABI стандарт, строго определяющий бинарный интерфейс для исключений. Убедите меня, что ваш язык лучше Python-а. В питоне есть исключения (и лямбды, и ещё чего всякого), а у вас нет.
Псевдо-исключения, коды возврата и try/catch — это какая-то каша. И вообще, скриптовый язык с кодами возврата — это жуть. Вы-же LLVM используете. Не смогли выяснить как там генерировать код выбрасывающий и ловящий исключения? К тому же для x86-64 существует ABI стандарт, строго определяющий бинарный интерфейс для исключений.
Проблема с плюсовыми исключениями та, что для его работы требуется суметь пробежаться вниз по стековым фреймам, находясь глубоко внутри стека вызовов. Гарантии, что это удастся сделать, можно дать только в том случае, если в стеке вызовов присутсвуют только функции, скомпилированные одним и тем же компилятором.
Для примера — код, генерируемый llvm 3.3 не уживался с g++ 4.8.2 на x86_64: в определённый случаях c++ (1) -> jancy (2) -> c++ (3) exception из с++ (3) не ловился в с++ (1). А когда стек вызовов вообще мультиязыковый, использовать плюсовые исключения — ну ненадёжно. Самый безопасный и прозрачный подход — коды возврата и потоковые переменные. Над этим насыпано синтаксического сахара, чтоб не было «жути» ;)
Убедите меня, что ваш язык лучше Python-а. В питоне есть исключения (и лямбды, и ещё чего всякого), а у вас нет.
ОК, попробую :) Исключения в Jancy есть, но в виде синтаксического сахара. Лямбды будут. А вот что у нас уже сейчас лучше чем в Питоне, так это работа с бинарными данными: безопасная адресная арифметика и инкрементальный разбор регекспами. И интеграция с си бесшовная, лучше чем в питоне. А ещё у нас есть реактивное программирование ;)
Но вообще вы абсолютно правы — сравнивать надо с Питоном. Это наша область применимости.
А зачем пробрасывать исключения через границу jancy->c++ или c++->jancy? Подход, который отлично работает не только в случае разных языков, но и просто разных модулей — это ловить все исключения на границе между языками/модулями и преобразовывать их в ошибки, которые понимаются другим языком/модулем. А после перехода границы, можно снова выбрасить исключение имеющее смысл уже для данного модуля. В общем, мне кажется, что ваша «ненадёжность» исключений основывается на их неправильном использовании.
Далее, с кодами возврата не всё гладко. Во первых, у вас появляется соглашение о том, что является ошибкой (null, -1, etc), а что нет. Во вторых, типа ошибки нигде нет. Напротив, в Питоне, например, тип ошибки — это тип исключения, и разные типы ошибок можно обрабатывать по-разному. В третьих, синтаксический сахар для обрабоки ошибок мне показался неудобным. Как пробросить ошибку через несколько уровней вызовов и сделать так, чтобы код промежуточных уровней остался не затронутым, т.е. не знал вообще что на нижнем уровне происходит ошибка, а на верхнем она обрабатывается? В вашем подходе на каждом промежуточном уровне прийдётся писать try.
Далее, с кодами возврата не всё гладко. Во первых, у вас появляется соглашение о том, что является ошибкой (null, -1, etc), а что нет. Во вторых, типа ошибки нигде нет. Напротив, в Питоне, например, тип ошибки — это тип исключения, и разные типы ошибок можно обрабатывать по-разному. В третьих, синтаксический сахар для обрабоки ошибок мне показался неудобным. Как пробросить ошибку через несколько уровней вызовов и сделать так, чтобы код промежуточных уровней остался не затронутым, т.е. не знал вообще что на нижнем уровне происходит ошибка, а на верхнем она обрабатывается? В вашем подходе на каждом промежуточном уровне прийдётся писать try.
А зачем пробрасывать исключения через границу jancy->c++ или c++->jancy? Подход, который отлично работает не только в случае разных языков, но и просто разных модулей — это ловить все исключения на границе между языками/модулями и преобразовывать их в ошибки, которые понимаются другим языком/модулем. А после перехода границы, можно снова выбрасить исключение имеющее смысл уже для данного модуля. В общем, мне кажется, что ваша «ненадёжность» исключений основывается на их неправильном использовании.
ОК, значит возникло недопонимание. Вы говорили про ABI-стандарт для исключений и я понял так, что предлагается ловить и бросать плюсовые исключения. Хорошо, значит мы сходимся в главном: исключения — в каком бы виде они ни были реализованы — на границах языков надо преобразовывать. Так вот, Jancy предлагает модель исключений, которая является *самой простой* при организации межязыковых взаимодействий. Причём в обе стороны: поймать Jancy-исключение = проверить код возврата и считать расширенную информацию об ошибке из TLS; бросить Jancy-исключение = записать расширенную информацию в TLS и вернуть «ошибочный» код возврата.
Далее, с кодами возврата не всё гладко. Во первых, у вас появляется соглашение о том, что является ошибкой (null, -1, etc), а что нет.
Совершенно верно. «Бросающие» функции должны следовать определённому протоколу.
Во вторых, типа ошибки нигде нет. Напротив, в Питоне, например, тип ошибки — это тип исключения, и разные типы ошибок можно обрабатывать по-разному.
Вступаю на взрывоопасную поверхность, поэтому дисклеймер: нижеследующее является не более, чем моим личным мнением ;) Я считаю, что сама концепция писать разные блоки catch под разные типы исключений — глубоко порочна. По сути стандартные типы исключений решают искусственную проблему — в блоке catch мы как правило хотим ловить *любые* исключения. Безусловно, вы можете придумать примеры, в которых надо проверять тип исключения и обрабатывать их в разных catch-ах. Но эти примеры всегда можно переписать так, что блок catch останется один. А во-вторых, подход Jancy ничему не противоречит — всегда можно проанализировать расширенную информацию об ошибке из TLS и построить соответвующее ветвление.
В третьих, синтаксический сахар для обрабоки ошибок мне показался неудобным. Как пробросить ошибку через несколько уровней вызовов и сделать так, чтобы код промежуточных уровней остался не затронутым, т.е. не знал вообще что на нижнем уровне происходит ошибка, а на верхнем она обрабатывается? В вашем подходе на каждом промежуточном уровне прийдётся писать try.
Вовсе нет. Если имеется глубокий стек вызовов из бросающих функций, и где-то в глубине произошла ошибка, то будет цепной возврат до ближайшего catch. Уже в нём вы вольны анализировать и обрабатывать это псевдо-исключение, основываясь на расширенной информации из TLS.
Безусловно, данная модель не универсальна и имеет ряд ограничений — например, нельзя бросать исключения из void-функций или функций, возращающих некие структуры. Обойти всё это можно, несколько подправив прототипы «бросающих» функций — так, чтобы они удовлетворяли протоколу псевдо-исключений Jancy. В целом же, согласитесь, ограничения присущи любой модели, и для эффективного её использования требуется некоторым образом «отформатировать» под неё мозг — уж к плюсовым исключеним это относится в полной мере ;)
Языки разрабатываются потому, что существующие чем то не устраивают. Это было, есть и будет всегда. Можно спорить конечно по поводу, насколько актуальны цели создания языка и как они достигнуты.
По моему цели сформулированы правильно и слабые стороны существующих языков определены верно. Языки послужившие базой это Си и Java. В Си адресная арифметика явно слабое место. Вообще ссылки основной источник ошибок. А в больших проектах это просто кошмар. Java пыталась с этим бороться но превращение всего в объекты меня лично напрягает. Я считаю, что проект интересный. Мне кажется, что если бы это был транслятор, а не интерпретатор то перспективы у него было бы значительно больше.
По моему цели сформулированы правильно и слабые стороны существующих языков определены верно. Языки послужившие базой это Си и Java. В Си адресная арифметика явно слабое место. Вообще ссылки основной источник ошибок. А в больших проектах это просто кошмар. Java пыталась с этим бороться но превращение всего в объекты меня лично напрягает. Я считаю, что проект интересный. Мне кажется, что если бы это был транслятор, а не интерпретатор то перспективы у него было бы значительно больше.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Jancy — скриптовый язык для системных/сетевых программистов