Читабельность Rust, C++ и Go

Твой вопрос был про то, какие design decisions в c++ определяют его нишу. Я привёл те решения, которые лично мне кажутся наиболее судьбоносными. Но не жди, что я буду тебе эти решения продавать как правильные или удачные: не люблю c++.

2. Zero overhead

Относительно чего? :-)

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

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

методы у структур, инкапсуляция, наследование реализации, рантайм- и компайлтайм- полиморфизм

Это всё всего лишь сахар над Си :-)

Так можно договориться до того, что Go — это просто сахар над шестнадцатеричными машинными кодами. Где по-твоему проходит граница между сахаром и не-сахаром?

Т.е. на языке шаблонов цепепе можно писать целые HTTP-серверы и клиенты, которые будут работать прямо в компайл-тайме :-)

Ну вот, например, в компайлтайме генерируют парсер регулярного выражения (то есть в рантайме фаза компиляции регулярного выражения будет отсутствовать): static regexes require no state tables, virtual functions, byte-code or calls through function pointers that cannot be resolved at compile time.

Люди на практике пишут compile-time algorithms.

Эта тьюринг полнота шаблонов как не пришей кобыле хвост :-)

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

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

Сравнил книгу и код :-) Или ты код тоже может также быстро читать как книгу, что аж глаза устают от беготни слева направо? :-) Ну ты крут, что тут сказать :-)

Такая фича в приложениии к программному коду не нужна.

И поэтому во всех редакторах кода, от vim до IDEA, такая фича давно уже как есть :-) Потому что не нужна, очевидно :-) Лол :-)

В XXI веке есть редакторы, которые умеют автоматически переносить длинные строки, если надо

Осмысленно переносить с учётом отступов и элементов синтаксиса или тупо обрубая на середине слова? Если первое, то можно ссылку на пример такого, если второе, то это просто нечитабельно.

как поддерживать код, если он не читаем?

Для начала делать нормальные переносы.

Читаемы все 3, да при том без всяких проблем.

Пример на плюсаъ вполне читаем. Или я просто привык к C++...

Так это еще без using namespace.

Тут можно using на возвращаемый тип, или using std::vector; using std::string;

namespace целый лучше не надо тащить.

А в Rust ужасно выглядят <'a> &'a (не знаю: что это значит, так как не знаком с этим языком).

Что это за догма такая - лимитировать строку в 80 символов? :-)

Ну да. Писать надо так: https://static.pexels.com/photos/239898/pexels-photo-239898.jpeg

Лайфтаймы. По началу тоже было ужасно, но затем привык и стало... привычно.

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

А можно пример языка, в котором этот принцип не соблюдается? :-) Скажем, есть у меня программа на Java :-) Вчера вот вышла Java 9 с новым набором фич :-) Неужели моя старая программа на Java теперь может замедлиться? :-)

Ну вот, например, в компайлтайме генерируют парсер регулярного выражения (то есть в рантайме фаза компиляции регулярного выражения будет отсутствовать):

Нет, нет :-) Я тебе говорю про язык шаблонов :-) Под языком шаблонов, я имею в виду способ записи программ, которые будут выполнятся на стадии компиляции - т.е. я говорю о метапрограммировании :-) В цепепе нельзя метапрограммировать на цепепе :-) В цепепе можно метапрограммировать только с помощью инстанцирования шаблонов, вызывая некие побочные эффекты во время компиляции :-) Классика жанра - программа вычисления фибоначчи в компайл-тайме:

template<int I>
struct Fib { enum { S = Fib<I-1>::S + Fib<I-2>::S }; };

template<>
struct Fib<1> { enum { S = 1 }; };

template<>
struct Fib<0> { enum { S = 0 }; };

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

Так программисту во время компиляции недоступен сам цепепе :-) Взгляни на пример фибоначчей выше :-) Для вычисления фибоначчей в компайл-тайме пришлось это записывать в извращённом виде :-) Поэтому и скомпилировать из обычной строки регулярку автор вышеупомянутой либы не осилил, а навернул маппинг стандартного синтаксиса регурярки на синтаксис цепепе :-)

Писать надо так

Так не надо. Проблема с восьмидесятниками в том, что они сектанты. Строка в 82 символа? Ересь, сжечь. И начинают разрывать нормальный из-за этих несчастных 2 символов. При этом как и подобает сектантам все уже забыли отчего да почему именно 80. Записано в святом писании и все тут. Хотя даже святой Гвидо емнип согласился, что до 90 норм.

Осмысленно переносить с учётом отступов и элементов синтаксиса или тупо обрубая на середине слова? Если первое, то можно ссылку на пример такого, если второе, то это просто нечитабельно.

Первое :-) В IDEA так :-) Ребятам из JetBrains - большой респект :-) Вы молодцы! :-)

Открой любую книгу — если там строки будут по сотне букв, у тебя глаза устанут

Так открой и посчитай. Будет там 50-60 знакомест, но никак не 80. Так что эти 80 тебя утомляют не сильно меньше, чем 100. Просто вы взяли цифру с потолка (по историчеспим причинам), и лбом поклоны бьете.

В случае плюсов должен быть vector<string*> тогда уж.

А вообще афтар ниасилил, но признаться себе в этом стесняется.

Хотя даже святой Гвидо емнип согласился, что до 90 норм.

Согласен. В DrRacket, в котором читабельности уделено очень большое внимание, ограничение 102 символа.

Согласен. В DrRacket, в котором читабельности уделено очень большое внимание, ограничение 102 символа.

Потому что в Лиспе, где любят писать размашистым почерком (тот же Эдмунд Вейтц), 80 символов на строку - вообще не вариант :-) Хотя, многие адепты чтут число «80» и в этих ваших лиспах :-) Лол :-)

Нет, нет :-) Я тебе говорю про язык шаблонов :-)

И я говорю ровно о нём же.

программисту во время компиляции недоступен сам цепепе

Да. Но это уже второстепенно, с моей точки зрения.

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

А можно пример языка, в котором этот принцип не соблюдается? :-)

Относительно голого Си? :) Например, Java ;)

Прикол в том, что все 3 языка не блещут «читабельностью»!

Переписать с нуля и поддерживать дальше?

так себе вариант, но многие пользуются

не надо код поддерживать :-) написал и забыл :-)

с :-) тобой :-) все :-) понятно :-) ощем-та :-)

индусы решат этот вопрос

даже индусы - лимитированный ресурс

Ты написал не тот же самый код для раста. В с++ ты вернул аллоцированные на куче строки, а в расте венул указатели на содержимое памяти TFile. Эквивалетный код будет

а как же лайфтаймы? без них-то более менее с этим не спорю

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

То есть, ты решил сравнить объект со ссылкой, для которой пришлось указать время жизни? Интересно, и что из них эффективнее?

собсна вопрос не про эффективность а про читабельность. если заморачиваться с лайфтаймами, то можно застрелиться кмк)

Сравниваешь с Python, и прям аж сам себе завидуешь:

динамическая типизация - она такая

В C++ ты можешь сделать using namespace std, и код станет более читабельным

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

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

Читабельность C++ зависит от кривизны рук программера

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

Очевидно корпорации как раз это понимают, поэтому никакого энтузиазма у них ржавый не вызвал.

Его и придумали чтобы заменить цепепе :-)

и :-) GC :-) туда :-) добавили :-) чтобы :-) заменить :-) c++ :-) ?:-)

пример кода на Rust не является аналогичным

но является примером кода на Rust

Мне кажется, коду не хватает форматирования, чтобы быть читаемым.

не помогло, имхо

Раст по умолчанию ругается на имена переменных в кэмел-кейс.

хосспади

ты первокурсник=)

я еще не родился, если чо

в коде C++ убрать ненужный std::, TFile* обернуть шарепойнтером и будет читабельно, в отличие гоуносрастов

Чувак, ну жто уже лисп какой-то. Сбалансируй уж тогда разделители.

Как минимум, С++ и раст код не эквивалентен.

но изуродовать так код на Go и на C++ можно только специально

Это ты еще scala код какого-нибудь (shapeless|catz|scalaz)-наркомана не видел.

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

Для начала делать нормальные переносы.

в примерах переносы специально одинаковы для всех языков

Лайфтаймы. По началу тоже было ужасно, но затем привык и стало... привычно.

стокгольмский синдром?

Прикол в том, что все 3 языка не блещут «читабельностью»!

а что блещет?

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

сомневаюсь что индусов так много

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

теперь ясны истоки вашего хейтерства плюсов

а где возвращаемое значение?

def typeList(arch: TFile, offset: int, parseDecl: bool) -> list:

выглядит как результат пищеварительного процесса змеи

тайпхинтинг через комменты

выглядит как результат змеиного пищеварительного процесса, который решили использовать для удобрения полей

но является примером кода на Rust

Думаете на GO\Python нельзя сделать плохочитаемую конструкцию? (=

Ну не знаю. Может у меня глаз замылен, но варианты go и c++ мне кажутся настолько ясными, что яснее некуда, хоть go я не знаю. Вот rust-запись действительно не очень понятна, но это, наверно, потому, что rust'а я тоже не знаю.