Re[11]: Carbon - Компьютерные священные войны

Здравствуйте, so5team, Вы писали:

S>Чтобы можно было отличать переменные от констант.
Есть const — значит константа, нет cons — значит переменная, без всяких там var вначале.

S>вот тут стоп. В современном коде тип указывается все реже и реже. Вписывать auto или const auto -- это тоже самое, что и вписывать var или let.
А тут видимо я тебя не понял. Я про пример в стартовом сообщении. В нем var используется чтобы показать, что объявляется переменная.

var r: f32;

S>Потому что сейчас вместо int f(int) зачастую приходится писать что-то вроде:
S>

S>template<typename T>
S>[[nodiscard]] constexpr typename T::value_type
S>f(T && v) noexcept;
S>

S>Что выглядит так себе. Особенно в коде тех утырков, которые застряли в "Си с классами" и продолжают лепить имя функции на той же строке, что и тип возвращаемого значения

А как тут наличие fn или func поможет?

S>Ну так все течет, все изменяется. Не менялось бы, мы бы на старославянском бы сейчас общались.
Были бы изменения к лучшему — никто бы не спорил.

Здравствуйте, rFLY, Вы писали:

S>>Чтобы можно было отличать переменные от констант.
FLY>Есть const — значит константа, нет cons — значит переменная, без всяких там var вначале.

Еще раз. Сейчас все чаще приходится писать:

auto i = 0;
const auto j = 42;

Это ничуть не лучше (а в чем-то и хуже), чем условные:

var i = 0;
let j = 42;

S>>вот тут стоп. В современном коде тип указывается все реже и реже. Вписывать auto или const auto -- это тоже самое, что и вписывать var или let.
FLY>А тут видимо я тебя не понял. Я про пример в стартовом сообщении. В нем var используется чтобы показать, что объявляется переменная.

Ну да. И в общем случае начинать описание локальных переменных с var лучше, чем с имени типа.

std::vector<some_type>::const_iterator start = v.begin();

против:

var start: std::vector<some_type>::const_iterator = v.begin();

Сразу видно, что начинается объявление переменной, а не хз чего. Например, далеко не все поймут, что такое в C++:

std::vector<some_type>::const_iterator start();

S>>Потому что сейчас вместо int f(int) зачастую приходится писать что-то вроде:
S>>

S>>template<typename T>
S>>[[nodiscard]] constexpr typename T::value_type
S>>f(T && v) noexcept;
S>>

FLY>А как тут наличие fn или func поможет?

func f<T>(T && v) constexpr noexcept -> typename T::value_type;

Здравствуйте, rFLY, Вы писали:

FLY> R>Не должен он быть лаконичным, он должен обеспечивать хорошую читаемость.

FLY> Если что-то можно выразить меньшим набором слов, разве это не скажется на читаемость в лучшую сторону?

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

avalon/3.0.2

A>https://github.com/carbon-language/carbon-lang?tab=readme-ov-file

A>Обсуждали уже?

Да, немного: Новый убивец С++

Но там похоже даже документации нет.

https://github.com/carbon-language/carbon-lang/tree/trunk/docs#guides

The guides/ directory contains to-be-written end-user documentation for developers writing programs in Carbon.

S>Но что-то делать нужно. Вот они и решили сделать новый ЯП, который типа как Rust, но чуть ли не со 100% интероперабильностью с C++. Тем самым можно оставить существующую кодовую базу на C++, а новые куски к ней дописывать на Carbon.

Там move semantic по умолчанию как в Rust или нет?

Здравствуйте, m2user, Вы писали:

S>>Но что-то делать нужно. Вот они и решили сделать новый ЯП, который типа как Rust, но чуть ли не со 100% интероперабильностью с C++. Тем самым можно оставить существующую кодовую базу на C++, а новые куски к ней дописывать на Carbon.

M>Там move semantic по умолчанию как в Rust или нет?

Мне этот язык не интересен.

По беглому поиску можно предположить, что они сами еще не определились:

https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/README.md#lifetime-and-move-semantics
https://github.com/carbon-language/carbon-lang/discussions/2352

Хотя непонятно, насколько эта информация протухла (или нет).

Здравствуйте, Pzz, Вы писали:

Pzz>Я чё-то не понял. А зачем у них int гвоздями прибит к i32?
А к чему его прибивать? Может а Go не так? (не знаю)

Здравствуйте, pagid_, Вы писали:

Pzz>>Я чё-то не понял. А зачем у них int гвоздями прибит к i32?
_>А к чему его прибивать? Может а Go не так? (не знаю)

К сишному ABI на данной платформе. В Go именно так и сделано. Иначе interop с С/C++ будет очень геморройным.

Здравствуйте, rudzuk, Вы писали:

R>Не скажется. Код на многословной Ада читается лучше, чем на лаконичном Обероне, где шиза лаконичности победила здравый смысл. Примеры, когда многословность улучшает читаемость, а лаконичность ухудшает.
Сдуру можно что угодно нагородить, язык то тут причем? Потому что позволяет это?

Здравствуйте, rFLY, Вы писали:

FLY> R>Не скажется. Код на многословной Ада читается лучше, чем на лаконичном Обероне, где шиза лаконичности победила здравый смысл. Примеры, когда многословность улучшает читаемость, а лаконичность ухудшает.

FLY> Сдуру можно что угодно нагородить, язык то тут причем? Потому что позволяет это?

В том числе. Язык должен стимулировать писать читаемый код.

avalon/3.0.2

Здравствуйте, rudzuk, Вы писали:

R>В том числе. Язык должен стимулировать писать читаемый код.
Так в твоем примере каждый оператор по отдельности читаемый, но кто-то их собрал в кучу, как тут прикажешь языку решать, что это не по фэншую? Вообще эти операторы убрать?

Здравствуйте, rFLY, Вы писали:

FLY> R>В том числе. Язык должен стимулировать писать читаемый код.

FLY> Так в твоем примере каждый оператор по отдельности читаемый, но кто-то их собрал в кучу, как тут прикажешь языку решать, что это не по фэншую? Вообще эти операторы убрать?

Заменять кракозябры словами. Писать больше, зато читать легче. Кракозябры не нужны.

avalon/3.0.2

Здравствуйте, so5team, Вы писали:

S>Еще раз. Сейчас все чаще приходится писать:
S>

S>auto i = 0;
S>const auto j = 42;
S>

S>Это ничуть не лучше (а в чем-то и хуже), чем условные:
S>

S>var i = 0;
S>let j = 42;
S>

Тут ка раз проще ошибиться и не заметить (те же 3 символа, что и в var), что константу, значение которой ты бы не хотел чтобы менялась, объявил переменной.

S>Ну да. И в общем случае начинать описание локальных переменных с var лучше, чем с имени типа.
На вкус и цвет...

FLY>>А как тут наличие fn или func поможет?
S>

S>func f<T>(T && v) constexpr noexcept -> typename T::value_type;
S>

Так пожалуйста, в таких случаях пусть будет func, примерно как delegate в С#, для функций с телом зачем указывать, что она func?
Ведь никого не смущает, что в for (c: Circle in circles) переменная объявлена без var. Почему бы и не быть исключениям когда они уместны.

Здравствуйте, Pzz, Вы писали:

Pzz>К сишному ABI на данной платформе. В Go именно так и сделано. Иначе interop с С/C++ будет очень геморройным.
И на каких платформах с int не в 32 разряда Go работает? На каких-то микроконтроллерах? На МS-DOS, на Win16 ?

Здравствуйте, Pzz, Вы писали:

Pzz>К сишному ABI на данной платформе. В Go именно так и сделано. Иначе interop с С/C++ будет очень геморройным.

С C++ будет непросто. А сишные функции я еще из Фортрана вызывал. Как и фортрановские из Сей. В MS DOS, Полуоси, Винде. Говорят, в Linux тоже работает, но это уже без меня делали.

Здравствуйте, rudzuk, Вы писали:

R>Заменять кракозябры словами. Писать больше, зато читать легче. Кракозябры не нужны.
Так я про лаконичность (количество слов), а не про их длину. Заменяя "кракозябрры" словами, ты получишь ровно тоже количество. Т.е. я про то, чтобы писать "int a;", вместо, утрируя, "Объявление переменной a типа int".

Здравствуйте, rFLY, Вы писали:

S>>

S>>var i = 0;
S>>let j = 42;
S>>

FLY>Тут ка раз проще ошибиться и не заметить (те же 3 символа, что и в var), что константу, значение которой ты бы не хотел чтобы менялась, объявил переменной.

Вы уж определитесь к чему у вас претензии. Если к тому, что для определения переменной лучше сперва писать имя типа, а не ключевое слово (var, let, const или что-то другое), то эта ваша претензия не к месту. Если же вас смущает, что let легко перепутать с var (чё, серьезно?), ну так на let и var в принципе свет клином не сошелся. Более вменяемые разработчики ЯП, чем авторы Carbon-а, могут выбрать const и var или что-то другое.

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

S>>Ну да. И в общем случае начинать описание локальных переменных с var лучше, чем с имени типа.
FLY>На вкус и цвет...

Тогда к чему вопросы. Вы хотите, чтобы кто-то убедил вас что ваш вкус -- он самый правильный?

FLY>Почему бы и не быть исключениям когда они уместны.

Чем меньше исключений и частных случаев, тем лучше. А то если начинаешь разбираться сколькими способами в C++ можно проинициализировать переменную или сколькими способами можно указать использование концепта, так что-то совсем невесело становится.

	От:	rFLY
	Дата:	02.04.24 09:45
	Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	02.04.24 09:54
Оценка:

	От:	rFLY
	Дата:	02.04.24 10:03
	Оценка:	+1

От:	so5team	https://stiffstream.com
Дата:	02.04.24 10:13
Оценка:

	От:	rudzuk
	Дата:	02.04.24 10:24
	Оценка:	+1