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

Да и пофиг. Читабельность у Раста на самом деле хуже, чем в среднем по больнице

На самом деле в топикстарте все три фрагмента с точки зрения читабельности ужасны. Каждый по-своему :)

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

Дык!

А потом запустил код и пошел варить пельмени. Как раз успеешь, когда он отработает =). Хоть бы аннотации типов расставили, как в третьем питоне.

Ok. Спасибо за ответы.

А потом запустил код и пошел варить пельмени. Как раз успеешь, когда он отработает =).

«It may seem paradoxical to use an interpreted language in a high-throughput environment, but we have found that the CPU time is rarely the limiting factor; the expressibility of the language means that most programs are small and spend most of their time in I/O and native run-time code.»

В данном конкретном случае наилучшая читаемость у Go :-) Его и придумали чтобы заменить цепепе :-) Раст тоже придумали, чтобы заменить цепепе :-) Но на раст смотреть без слёз не получается, как и на цепепе :-)

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

Как ходить босиком, если обут в сапоги? :-) Лол :-)

Кстати, почему ты сравниваешь именно го, раст и цепепе? :-) Потому что понимаешь, что го вне конкуренции в этом качестве? :-)

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

Знаешь, что общего у Go и Java? Автоматическое управление памятью со сборщиком мусора. Поэтому «заменить цепепе» они не способны в принципе.

Как уже говорили, приведённый пример кода на Rust не является аналогичным, а аналогичный

fn typeList(arch: &TFile, offset: u32, parseDecl: bool) -> Vec<String> {

Выглядит лучше всех, т.к. в гоу смущает []BStr и uint32, Rust'овый u32 выглядит лучше. C++ асасай, на этом моё компетентное мнение заканчивается.

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

fn type_list<'a>(
    arch: &'a TFile<'a>,
    offset: u32,
    parse_decl: bool) -> Vec<&'a str> {
    ...
}

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

Да всё равно получается ворох закорючек, как ты по строкам их ни перекладывай.

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

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

Знаешь, что общего у Go и Java? Автоматическое управление памятью со сборщиком мусора.

Знаю, и что? :-)

Поэтому «заменить цепепе» они не способны в принципе.

Да что ты говоришь :-) А вот в Гугле считают иначе :-) Прочитай первые два абзаца отсюда - https://talks.golang.org/2012/splash.article и тебе станет всё понятно :-)

а как насчет perl?

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

Да всё равно получается ворох закорючек, как ты по строкам их ни перекладывай.

Читаемых закорючек! В этом же был пойнт?

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

Молодец, распетушил объявление функции на 5 строк. Ну что не слелаешь ради тупого канпелятора убогонького недоязычка!

В оригинале объявление функции всё равно не укладывается в каноничные 80 символов, и его придётся разбивать. Или ты из хипсторов с широкоформатными мониторами?

В питоне я тоже так делаю, когда, например, у функциии много аргументов + дефолтные значения.

Поэтому «заменить цепепе» они не способны в принципе.

А вот в Гугле считают иначе :-)

Да это понятно, что они там много про себя считают. Каждая более-менее крупная шарага рано или поздно решает изобрести очередного NIH «убийцу цепепе». Sun -> java, microsoft -> c#, google -> go, mozilla -> rust, и так далее. И на самом деле некоторые из них находят свою (не слишком-то широкую) нишу. А цепепе по-прежнему живее всех живых.

Посмотрим, может быть у rust и получится...

В оригинале объявление функции всё равно не укладывается в каноничные 80 символов

И что, лол? :-)

Или ты из хипсторов с широкоформатными мониторами?

А ты из тех, кто в текстовом режиме работает и код на принтере распечатывает? :-) Что это за догма такая - лимитировать строку в 80 символов? :-) В XXI веке есть редакторы, которые умеют автоматически переносить длинные строки, если надо :-) Придумали догму и морочат головы своими 80x25 :-)

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

а как насчет perl?

Хвала Аллаху, хотя бы этот - уже точно закопан.

ворох закорючек

Читаемых закорючек!

ворох
читаемых

Взаимоисключающие параграфы.

У такого подхода есть и минусы, это проявляется когда нужно отдать изменяемую ссылку на поле структуры. Например есть такая структура:

struct Point {
    x: u32,
    y: u32,
}

impl Point {
    fn get_x(&mut self) -> &mut u32 {
        &mut self.x
    }

    fn get_y(&mut self) -> &mut u32 {
        &mut self.y
    }
}

get_x и get_y отдают ссылку только на часть обьекта, но по сигнатуре не понятно на какую именно часть. Поэтому такой код будет работать:

    let mut p = Point{x: 1, y: 2};
    *p.get_x() = 3;
    *p.get_y() = 4;

А такой код уже не будет работать:

    let mut p = Point { x: 1, y: 2 };
    let px = p.get_x();
    let py = p.get_y();
    *px = 3;
    *py = 4;

https://play.rust-lang.org/?gist=077dd7f656ec26b4696cafe522684b64&version...

А цепепе по-прежнему живее всех живых.

Среди маргинальщины - да :-) Но его время уже проходит :-) Сейчас не нужно (да и глупо) тратить 10 лет на овладение гигантским языком ради непонятно чего - ради того, что в нём отсутствует сборщик мусора :-) Лол :-) Куда гораздо более разумней изучить C (как основу) и пару-тройку высокоуровневых языков - от Питона до Го, от JavaScript до SQL, чем тратить дни и ночи многих лет на то, чтобы научиться писать закорючки :-) Да ещё и без IDE, как многие советуют, а то с IDE не так мучительно и из пионэра не получится настоящий знаток цепепе :-) Лол :-)

Зачем ты написал свои примеры? Какие выводы? Они все нечитаемы? Нечитаем только один? Если ты считаешь, что это нечитаемо, то вангую - ты первокурсник=)

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

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

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

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

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

Сейчас не нужно (да и глупо) тратить 10 лет на овладение гигантским языком ради непонятно чего - ради того, что в нём отсутствует сборщик мусора :-)

Всё зависит от решаемых задач. В любой ЯП неизбежно вшит набор компромиссов (design choices), который определяет нишу этого языка. Непредсказуемость в поведении программы, которую вносит сборщик мусора, уместна не во всех ситуациях. И если цепепе, це, и раст в эти ситуации могут, то с го там искать в принципе нечего.

Вот интересно, что мешает Го стать убийцей жабки или там сисярпа?

Че, правда не знаешь что мешает? Подсказка: три буквы, первая О, в го не завезли.

пиши на пхп лол

function (
  File & $arch, 
  int $offset, 
  bool parseDectl
) : bstrCollection {
}

В любой ЯП неизбежно вшит набор компромиссов (design choices), который определяет нишу этого языка.

А какой набор компромиссов (design choice) вшит в цепепе? :-) По-моему, там было желание изобретателя программировать на C как на Simula :-) Потом главным компромиссом стало обеспечение обратной совместимости и совместимости с Си :-) В итоге так появился не набор компромиссов, а набор костылей :-) Сейчас темпы загрузки костылей в стандарт стали расти :-) Кому они нужны - не известно :-)

И если цепепе, це, и раст в эти ситуации могут, то с го там искать в принципе нечего.

По цепепе я высказался :-) А в ситуациях, где нужно без GC (а таких ситуаций очень не много) просто берётся Це и всё :-)

Вот интересно, что мешает Го стать убийцей жабки или там сисярпа?

А кто мешает футболистам стать баскетболистами? :-)

А ты из тех, кто в текстовом режиме работает и код на принтере распечатывает? :-)

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

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

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

С выпускником филологического мне сложно быть на одной ноге.

А какой набор компромиссов (design choice) вшит в цепепе?

Их очень много, см http://colinm.org/language_checklist.html . Из наиболее существенных _имхо_ :

1. Обратная совместимость с Си
2. Zero overhead
3. Кагбе ооп-ность: методы у структур, инкапсуляция, наследование реализации, рантайм- и компайлтайм- полиморфизм
4. Шаблоны как средство кодогенерации: компайл-тайм рефлексия (убогая, но уж какая есть) в сочетании с тюринг-полнотой

3. Кагбе ооп-ность: методы у структур, инкапсуляция, наследование реализации, рантайм- и компайлтайм- полиморфизм

Просто интересно: если это «кагбе ооп-ность», то как тогда выглядит Ъ-ооп-ность? Как в JS/Self?

Спасибо, интересный пример.

We live in a world where programmers think of Java's Object model when they think of OOP.

Which is a crippled version of C++'s Object Model.

About which Alan Kay said: 'Actually I made up the term «object-oriented», and I can tell you I did not have C++ in mind.'

Просто интересно как тогда выглядит Ъ-ооп-ность?

Мне это, напротив, безразлично.

а почему ты сердишься? может ты юпитер? может ты неправ?

Просто интересно: если это «кагбе ооп-ность», то как тогда выглядит Ъ-ооп-ность? Как в JS/Self?

Как в CLOS или в SmallTalk :-)

About which Alan Kay said: 'Actually I made up the term «object-oriented», and I can tell you I did not have C++ in mind.'

Ну, многие почему-то любят эту фразу, но забывают, что:

- когда Кей стал делать SmallTalk, ООП в виде Simula уже был;

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

Но да, бездумно цитировать Кея — это проще.

Но да, бездумно цитировать Кея — это проще.

Тебе непременно нужен ход мыслей? Хорошо, вот тебе портянка-брейндамп.

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

А то, что получилось у Страуса - с их точки зрения это лишь одна из возможных интерпретаций ООП, причем далёкая от сферических в вакууме идеалов.

Почему они настаивают на том, что сообщене-обменно-оприенированное называется объектным — хз.

Теперь разрослась популяция разработчиков, которые с какого-то бодуна считают, что эталонное Ъ ООП - это когда есть связка из наследования+полиморфизма+инкапсуляции. Лично мне их видение кажется зашоренным и абсурдным, ну да это их проблемы, что им приходится с этим жить.

Ну и получается, что за термин «Ъ ООП» конкурируют как минимум две чудоковатых школы. Лезть в их горячий спор — идиотское занятие ;)

IMHO, понятие True-OOP к C++ неприменимо. C++ - практичный язык, сделанный для решения широкого круга реальных задач. Для этого в него собрали большое количество инструментов, которые требуются для решения разных задач (и неважно, из какой парадигмы этот инструмент). При этом постарались совместить их, чтобы они более менее друг с другом работали совместно (где это возможно). В результате получился удобный инструмент для решения широкого круга реальных задач, причем далеко не идеальный (парадигм там много, и насколько тамошнее OOP является True пользователям C++ насрать).

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

1. Обратная совместимость с Си

Согласен :-)

2. Zero overhead

Относительно чего? :-) Относительно Си? :-) Ну это за счёт шаблонов и встраиваемых функций, которые якобы раскрываются компилятором и на выходе получается оптимизированный код, как если бы не было бы никаких абстракций :-) На этом концепция «zero overhead» заканчивается, и начинается реальность :-) А в реальности цепепе даже нормально строчку в компайл-тайме не может сгенерить :-) Приходится генерить в рантайме :-) Где тут zero overhead - не понятно :-)

3. Кагбе ооп-ность: методы у структур, инкапсуляция, наследование реализации, рантайм- и компайлтайм- полиморфизм

Это всё всего лишь сахар над Си :-) Чтобы программист меньше страдал такой фигнёй, как определение vtable и тэгирование объектов вручную :-)

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

Эта тьюринг полнота шаблонов как не пришей кобыле хвост :-) Что с ней делать с той тьюринг полнотой? :-) Тьюринг полнота означает то, что можно запрограммировать любой алгоритм :-) Т.е. на языке шаблонов цепепе можно писать целые HTTP-серверы и клиенты, которые будут работать прямо в компайл-тайме :-) Сможешь такое провернуть? :-) Лол :-)

ООП в динамически-типизированных языках и в статически-типизированных языках в принципе должно выглядеть по-другому

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

Я так понял, что некие авторитеты (может, тот же Кей, не помню, да и мне пофиг) почему-то ассоциировали (или до сих пор ассоциируют, опять же, плевать) с ООП две вещи

Ну странно спорить с изобретателями ООП, мол чет не то вы там напридумывали, я, вася пупкин, свое мнение имею! А то есть такие, что сахарок в виде foo.bar() над bar(foo) уже называют ООП. Ну а чо, вона точку видишь, вызов метода нах! ООП без базару.

А то, что получилось у Страуса - с их точки зрения это лишь одна из возможных интерпретаций ООП, причем далёкая от сферических в вакууме идеалов.

Вот это вот ты верно заметил :-)

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

Более того, разрослась популяция разработчиков, который считают, что Ъ-ООП - это когда такой вот синтаксис: object.method1() :-) Когда Страуструп предложил внести в стандарт поддержу раскрытия вызова f(x,y) в x.f(y), поднялся вой на тему не Ъ-ООП :-) Вот что пишет сам Страуструп об этом:

I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would seriously compromise their ability to design stable interfaces.

Если кому интересно тут полная версия :-) Лол :-)

Тебе непременно нужен ход мыслей?

Нет, мне интересно, если у C++ среди мейнстримных статически-типизированных языков «кагбе ооп-ность», то что такое нормальное ООП.

Но нормального ответа не будет, я понял.

Нет, мне интересно, если у C++ среди мейнстримных статически-типизированных языков «кагбе ооп-ность», то что такое нормальное ООП.

Хотя бы как в Java :-) Там хотя бы додумались, чтобы объекты вложенных классов автоматически получали указатель на объекты окружающих классов :-) А в цепепе вложенные объекты не пойми зачем вообще нужны :-) Даже forward declaration сделать нельзя по-нормальному :-) Лол :-)

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

А ты из тех, кто в текстовом режиме работает и код на принтере распечатывает?

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

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

Ага, а еще считать дурным тоном (за несколькими исключениями) имена переменных в одну букву, «божественные» объекты и магические числа. Старперы, что с них взять!