Вышел Rust 1.3

Есть какой-то комплекс принципов, который позволил в питоне по-человески оформить те конструкции, которые в перле обычно записываются кроказябрами.

Что скажешь насчет последних синтаксических новшеств в Python 3.5? На «по-человечески» слабо походит.

Чем «очевиднее» утверждение, тем тяжелее дать ему внятное обоснование.

Некоторые вещи понятны интуитивно, например, очевидно: «Через любые две точки на плоскости можно провести прямую и притом только одну». Так и здесь очевидно, что для работы с памятью нужно вводить дополнительные сущности.

Из этих трёх самым практичным выглядит Го (при всей моей нелюбви к нему). А так смотря для чего. Если тебя интересует яблочная платформа (за пределами он даже если «заопенсорся», вряд ли, сильно вылезет), в первую очередь, то бери swift. Если что-то низкоуровневое/системное - попробуй раст. Иначе, опять же го.

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

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

Получается, старые сущности применяли без кракозябр, а новые сущности такие особенные, что без ушата всяких #[!]{{@!/*:?*/%={}} не обойтись? Это точно *очевидно* ?

И я до сих пор считаю, что замена ~ на Box<> была ошибкой... даже двумя ошибками.

Но зачем держать Box частью языка, а не библиотеки?

Получается, старые сущности применяли без кракозябр, а новые сущности такие особенные, что без ушата всяких #[!]{{@!/*:?*/%={}} не обойтись?

Очевидно, из законов комбинаторки при введении новых сущностей в кол-ве k получим (n+k)^m - n^m возможных вариантов совмещения новых сущностей со старыми. И от этой сложности никуда не деться.

Но зачем так драматизировать? Большинство кода вполне выглядит читаемо, если не погружаться в какие-нибудь сложные сырцы. Статически в 80% случаев вам будет попадаться простой читабельный код подобного плана https://github.com/PistonDevelopers/piston/blob/master/src/input/src/render.rs В остальных 20%, да вам придется поломать голову, но иначе не получится. В этом заключается стоимость ЯП без GC и c безопасным ручным управлением памятью.

Не хватает мозгов Не нравится, пользуйтесь Go или ожидайте, когда взлетит D.

Но зачем держать Box частью языка, а не библиотеки?

Я говорил только о синтаксисе. Насчет «части языка» - Box являлся ей (lang item) и остался ей, просто сейчас он не выделяется синтаксически.

Не нравится, пользуйтесь Go или ожидайте, когда взлетит D.

У Go и у D один и тот же фатальный недостаток — сборка мусора.

Очевидно, из законов комбинаторки при введении новых сущностей в кол-ве k получим (n+k)^m - n^m возможных вариантов совмещения новых сущностей со старыми. И от этой сложности никуда не деться.

Какое это имеет отношение к синтаксису?

Так ли хороша семантика, если не получается сопроводить её человечным синтаксисом?

Что значит человечным? Ты хочешь портянки в стиле паблик статик файнал Борщ что ли? Тебе указать путь? Ненавидимые тобой «закорючки» значительно улучшают скорость чтения сложного кода, если конечно понимать их смысл. Задолбали инвалиды, которые не зная матанязык зачем то пытаются читать код на нём.

Вот и сравни, что легче читается: паблик статик файнал Борщ vs $%^Борщ. Портянистость портянок это только усугубит, а вовсе не решит проблему.

&'x Box<Trait+'x>

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

Нужно подключить греческий алфавит.

Да. И немного иврита, чтобы грекам не показалось легко.

Что значит человечным?

Коротко ответить не могу, а развернутый ответ найдешь в этой книге http://www.ozon.ru/context/detail/id/16905899/ (и похуй, что прикладной областью там выбраны графические интерфейсы, а не портянки чудесного кода)

&'x Box<Trait+'x>

Нужно подключить греческий алфавит
И немного иврита

А выразите заключенную в описании информацию в «человечном» синтаксисе.

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

Вот и сравни, что легче читается: паблик статик файнал Борщ vs $%^Борщ

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

Да всё хорошо с box<>. Смири гордыню, и прими его всем сердцем, и всё у тебя будет хорошо.

Да всё хорошо с box<>

Ну да, вместо одной закорючки нужно написать две плюс идентификатор; и в результате получить не box, а ptr_to_boxed.

Смири гордыню, и прими его всем сердцем, и всё у тебя будет хорошо.

Ну, я пока не настолько завишу от растовских naming conventions %)

Этому языку не хватает закорючек.

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

&'x Box<Trait+'x>

У тебя тут написано, что где-то в сторонке заданы некий интерфейс Trait и некое время жизни x , а твоя запись описывает ссылку на экземпляр Box. Этот экземпляр имеет время жизни x , и параметризован интерфейсом Trait всё с тем же временем жизни x . Так?

Тогда предлагаю такое:
ref Lifetime Box<Lifetime Trait>

• ref — ключевое слово, наравне с уже имеющимся mut ;
  
• Не ясно, на кой ляд в оригинальной записи был нужен + , так что херачим через пробел;
  
• С лайфтаймами обращаемся как со второй независимой системой типов. Раз в оригинальной записи конкретный интерфейс обозначили словом Trait , то конкретное время жизни обозначаем как Lifetime ;
  
• Наверное, где-то понадобится ключевое слово lifetime , в чем-то подобное уже имеющемуся ключевому слову type .

И если уж делать для обозначения лайфтаймов обязательный префикс-кракозябру, то я выбрал бы «@», а не «'». Всё ж таки «Trait@Lifetime» читать гораздо естественнее, чем «Trait+'Lifetime»

Не совсем. Лайфтайм — такой же параметр параметризации, как и типаж. Это не совершенно отдельная сущность сбоку.

Так?

Очень близко.

ref Lifetime Box<Lifetime Trait>

То есть «человечность» сводится к замене sigils (некоторых) на слова и полуслова. Богатая идея.

ref — ключевое слово, наравне с уже имеющимся mut ;

Какое ключевое слово мы будем использовать вместо ref в pattern matching для связывания по ссылке? Как должно интерпретироваться ref x - как ссылка на объект типа x или как неправильно записанная ссылка с лайфтаймом?

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

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

Кстати, твое знание Rust потрясает.

С лайфтаймами обращаемся как со второй независимой системой типов

facepalm.jpg

Наверное, где-то понадобится ключевое слово lifetime

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

Лайфтайм — такой же параметр параметризации, как и типаж. Это не совершенно отдельная сущность сбоку.

В том смысле, что Box<Trait+'x> и Box<Trait+'y> — это два разных типа? Или ты что-то другое пытаешься мне объяснить?

портируй на Go.

То есть «человечность» сводится к замене sigils (некоторых) на слова и полуслова. Богатая идея.

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

Идея херачить через пробел чревата как минимум усложнением парсера

Так язык этот для людей разрабатывается, или для парсера?

сведение лайфтайма к идентификатору ухудшает локальную читабельно.

Возможно. С другой стороны, почему её не ухудшает сведение типа к идентификатору?

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

Сейчас у нас нечитабельная каша из кавычек...

В том смысле, что Box<Trait+'x> и Box<Trait+'y> — это два разных типа?

The more you know...
https://doc.rust-lang.org/nightly/nomicon/subtyping.html

Занятно. Благодарю

Что скажешь насчет последних синтаксических новшеств в Python 3.5? На «по-человечески» слабо походит.

:) Гвидо стареет.

То есть «человечность» сводится к замене sigils (некоторых) на слова и полуслова. Богатая идея.

Не сводится, но включает в себя.

Судя по приведенному примеру - сводится. Впрочем, если она включает в себя и что-то другое - что именно?

Чтобы программа на этом языке была похожа не на нотную запись птичьего чириканья

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

Так язык этот для людей разрабатывается, или для парсера?

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

сведение лайфтайма к идентификатору ухудшает локальную читабельно.

Возможно.

Без всяких «возможно». У тебя и тип, и лайфтайм изображаются идентификатором, а в «нечеловеческом» Rust лайфтайм четко помечен.

результате у тебя получится непарсабельная каша из идентификаторов.

Сейчас у нас нечитабельная каша из кавычек...

То есть ты предлагаешь заменить одну нечитабельную кашу на другую, но чтобы этой другой было в два раза больше. Прекрасное предложение.

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

Впрочем, если она включает в себя и что-то другое - что именно?

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

Если в исследования по читабельности гуйни денег и сил было вбухано до чёрта, то про аналогичные исследования по ЯП мне слышать не приходилось. Вот так целенаправленно занимались разве что читабельностью блок-схем, на выходе получился диалект блок-схем под названием «дракон». Документация у них не самая плохая, можешь глянуть, о чём именно они там толкуют.

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

Без односимвольных сокращений у пейсателя хотя бы не создастся иллюзии, что текст хорош. То, что казалось пейсателю остроумным однострочником, без чириканья развернётся на пол-экрана. Появится мотив херню свою декомпозировать на части, либо переформулировать в более простом виде.

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

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

Без всяких «возможно». У тебя и тип, и лайфтайм изображаются идентификатором, а в «нечеловеческом» Rust лайфтайм четко помечен.

Можно пометить его как-нибудь без закорючек?

То есть ты предлагаешь заменить одну нечитабельную кашу на другую, но чтобы этой другой было в два раза больше. Прекрасное предложение.

Первый шаг на пути избавления от каши — это перестать заметать её под ковёр ;)

Какое это имеет отношение к синтаксису?

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

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

Это как скорочтение, либо осилишь новый уклад, либо работай с Go/D/Java, если твой мозг не готов/не может выйти на новый уровень обработки информации.

Если хочешь получить более простой синтаксис, то тебе нужно избавляться от сущностей, а не заменять закорючки на слова и сокращения. Как это сделать? Ведь избавляясь от сущностей, ты избавляешься от концепций преложенных в Rust. И в итоге у тебя получится D или C++.

Получается, старые сущности применяли без кракозябр, а новые сущности такие особенные, что без ушата всяких #[!]{{@!/*:?*/%={}} не обойтись?

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

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

Стоит обратить внимание на ObjectPascal vs C/C++ чтоб увидеть как ты притягиваешь за уши этот аргумент.

ну и что, все равно ненужно

фиксед

Два чая адеквату!

Мне просто непонятно, неужели вот так было бы не проще и красивее?

x
// lifetime x
x.lt

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

И что - всё, что с маленькой буквы, явлется лайфтаймом? Или какие-то идентификаторы, начинающиеся с маленькой буквы, являются лайфтаймами, а какие-о - чем-то другим? Как различать будем?

В некоторых языках есть подобные конвенции, мне кажется это удобно.

Назови языки поимено.

Я выше уже дал книжку по принципам построения гуйни

А чего не на учебник по живописи или там книгу о вкусной и здоровой пище? Тоже нерелевантно, но хоть интересно или полезно.

Без односимвольных сокращений у пейсателя хотя бы не создастся иллюзии, что текст хорош. То, что казалось пейсателю остроумным однострочником, без чириканья развернётся на пол-экрана. Появится мотив херню свою декомпозировать на части, либо переформулировать в более простом виде.

Ты написал «нас ебут, а мы крепчаем», но развернул фразу на пол-экрана.

У тебя и тип, и лайфтайм изображаются идентификатором, а в «нечеловеческом» Rust лайфтайм четко помечен.

Можно пометить его как-нибудь без закорючек?

Можно, конечно. См. Кобол.

Первый шаг на пути избавления от каши — это перестать заметать её под ковёр ;)

Во-первых, каша - она в глазах смотрящего (или в его голове); во-вторых, ты не избавляешься от каши - ты варишь ее всё больше.

нерелевантно

Ну, раз ты не читал, то тебе, конечно, виднее.

нерелевантно

Ну, раз ты не читал, то тебе, конечно, виднее.

Мне хватило названия книги и идей, которые задвигает человек, ее прочитавший.

У математики-то как раз нет проблем с записью, кроме сильной зависимости от контекста.

&'x mut Нужно<Больше+'x> &-x`Разных<mul &Закорючек+'x>

И что - всё, что с маленькой буквы, явлется лайфтаймом?

Параметры типов.

Или какие-то идентификаторы, начинающиеся с маленькой буквы, являются лайфтаймами, а какие-о - чем-то другим? Как различать будем?

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

Назови языки поимено.

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

Если что-то низкоуровневое/системное - попробуй раст

А это какие задачи конкретно ты имеешь ввиду, куда бы ты засунул Rust?

И что - всё, что с маленькой буквы, явлется лайфтаймом?

Параметры типов.

Лайфтаймы указываются не только в параметрах типов.

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

Это не то, о чем ты говорил раньше.

Так ли хороша семантика, если не получается сопроводить её человечным синтаксисом?

Вообще хороший вопрос, но тут только время покажет.

А в тысячном одинаковом сраче про синтаксис я, пожалуй, не буду участвовать) Не был против, если бы он был более элегантным и последовательным, но меня и так устраивает. Мне гораздо интереснее, например, чем кончится http://aturon.github.io/blog/2015/09/18/reuse.

портируй на Go.

А? poly2tri или zoc? ) В обоих случаях go не будет подходящим инструментом, gc и все такое.