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

ARK>>"преобразования фурье, блочного шифрования, или аудио/видео кодека"?
ARK>>Однозначно низкоуровневые.

_>Ну обычно "низкоуровневые" это имеется ввиду ближе к железу. Типа там драйвера, работа с портами и т.п. А то что я перечислил — это скорее библиотечные алгоритмы. И тут получается что ты предлагаешь сделать в языке общего назначения индексацию неудобную для создания на этом языке библиотечных алгоритмов. А их ведь писать надо. Получается на другом языке. А кто должен будет соединять индексацию библиотек и языков их использующих? Вот надо передать индекс в библиотеку, кто должен делать в правильных местах +1 и -1? Библиотека? Так ей не положено — использовать её могут из любого языка. Программист на предлагаемом языке с индексацией с 1? Так ему геморрой.

_>И будет ли людям удобно переключаться с одного языка на другой, с разными правилами индексации, в пределах одного проекта? Часто же одновременно делаются и библиотечные алгоритмы и прикладной код. Или смотрешь в отладчике на индекс, и думаешь "а с 1 он или с 0?". Как быстро коллектив решит забить и всё писать на языке пригодном и для разработки и того и другого?

_>>>Какие преимущества имеет индексация с 1, которые перевешивают неудобства при решении целых классов реальных задач?

В целом я с вами согласен, сейчас нет особого желания ломать копья, тем более, что некоторые граждане уже спешат объявить альтернативную точку зрения "троллизмом".
Моя позиция скорее о том, как бы мне хотелось, чтобы было (в идеальном сферическом мире в вакууме). Где язык своего рода абстрактное средство передачи знаний, не привязанное к битам и байтам, и прочим кольцевым буферам. А не о том, чтобы взять и в реальный проект вот прямо сейчас вкорячить новый язык с индексацией от единицы.

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

C>>К примеру, организация кольцевого буфера: x[num % x.length]. Всё красиво и понятно. На паскалеподобной гадости будет: "x((num-1) mod x.length +1)" — офигеть как красиво. И это ещё цветочки.
ARK>Хм. Ну, во-первых, паскалеподобная гадость для меня выглядит понятнее, чем си-подобная.
ARK>Во-вторых, это не Паскаль, а Ада какая-то. Почему у массива круглые скобки?
Вот вид скобок как раз пофиг.

ARK>В-третьих, у вас похоже ошибка, зачем к длине 1 прибавлять?
Затем. Посчитай что получится при длине в 5 элементов и num==6.

ARK>Короче должно быть x[(num — 1) mod x.length]. По-моему, отлично выглядит, адского криминала нет, тем более, что кольцевые буферы это тоже весьма специфическая вещь.
Неа. У меня правильно написано было.

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

Уродливо. Лучше всего у Питона:

b=c; d = e if a==b else f

AN>

AN>// пример 3 на Си
AN>b = c;
AN>d = a==b ? e : f;
AN>

Терпимо.

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

C>Затем. Посчитай что получится при длине в 5 элементов и num==6.
C>Неа. У меня правильно написано было.

Да, у вас все правильно, я ошибся.

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

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

C>Уродливо. Лучше всего у Питона:
C>

C>b=c; d = e if a==b else f
C>

По-моему, у Питона как раз уродливее некуда.

Лучше всего было бы, если бы if был в двух формах — статемента и выражения.
Соответственно, в форме выражения было бы нечто типа:

d := if a = b then e else f end

Лично мне такой вариант больше нравится.

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

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

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

C>>Уродливо. Лучше всего у Питона:
C>>

C>>b=c; d = e if a==b else f
C>>

ARK>По-моему, у Питона как раз уродливее некуда.

ARK>Лучше всего было бы, если бы if был в двух формах — статемента и выражения.

О господи, ещё и у if-а две формы теперь! А вот знаете, можно вызов любой функции написать и как статемент, и как выражение:

f(); // statement
x = f() + 1; // выражение

Да и вообще во всех языках, какие я помню, в БНФ присутствует:
statement := expression | ...

Чем же if хуже, что вы его так обижаете?

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

D>О господи, ещё и у if-а две формы теперь! А вот знаете, можно вызов любой функции написать и как статемент, и как выражение:

D>f(); // statement
D>x = f() + 1; // выражение

В моем понимании первое выражение — это процедура, а не функция. Нечто с побочным эффектом.
В Eiffel так и сделано, и это правильно, ИМХО.
Так что не "любой функции", а "любой функции в C++ или Java".

D>Да и вообще во всех языках, какие я помню, в БНФ присутствует:
D>statement := expression | ...

Ну, далеко не каждый statement содержит expression.
Вызов процедуры — не содержит.

D>Чем же if хуже, что вы его так обижаете?

if, case/switch, foreach (в таких формах, например — http://bertrandmeyer.com/2010/01/26/more-expressive-loops-for-eiffel/) — вот эти языковые конструкции могут быть в двух формах (statement и expression), остальное не нужно, ИМХО.

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

D>>Да и вообще во всех языках, какие я помню, в БНФ присутствует:
D>>statement := expression | ...

ARK>Ну, далеко не каждый statement содержит expression.

Все математики рассеянные, но не все рассеянные — математики.

ARK>вот эти языковые конструкции могут быть в двух формах (statement и expression)

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

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

ARK>>вот эти языковые конструкции могут быть в двух формах (statement и expression)

D>А могут быть в одной, что делает язык и проще, и функциональнее.

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

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

ARK>Могут. Но на мой взгляд это очень плохо. Выделение статементов предотвращает опасные вещи — побочные эффекты в выражениях.

И каким же образом оно их предотвращает? Оно чё, запретит тебе писать функции с побочными эффектами? Предотвращает как раз функциональный стиль, а в ФЯ как раз-таки всё — выражения и нет мутабл-переменных.

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

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

ARK>>Могут. Но на мой взгляд это очень плохо. Выделение статементов предотвращает опасные вещи — побочные эффекты в выражениях.

D>И каким же образом оно их предотвращает? Оно чё, запретит тебе писать функции с побочными эффектами?

Именно так. Процедура делает побочные эффекты, но ничего не возвращает. Функция возвращает значение, но не может никаких побочных эффектов. Как в Ada'83.

D>Предотвращает как раз функциональный стиль, а в ФЯ как раз-таки всё — выражения и нет мутабл-переменных.

Чтобы достичь "функционального стиля" в ЯП общего назначения, надо запретить указатели или вводить линейные/уникальные типы. И даст ли это преимущество перед разделением на статементы/операторы — вопрос открытый.

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

ARK>Чтобы достичь "функционального стиля" в ЯП общего назначения, надо запретить указатели или вводить линейные/уникальные типы.

Не надо его достигать, надо просто на нём писать. А где это удобнее и выгоднее, забивать и писать в императивном. См. пример оптимизированной mutable-реализации immutable-класса List в книге Одерски "Programming in scala". Поэтому и запрещать ничего не надо.

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

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

C>Уродливо. Лучше всего у Питона:
C>

C>b=c; d = e if a==b else f
C>

А еще лучше у сами знаете когоNemerle:

b = c;
d = if (a == b) e else f;

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

ARK>Да, у вас все правильно, я ошибся.

В итоге ты идеально обосновал "пользу" индекса, начинающегося с 1

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

D>А могут быть в одной, что делает язык и проще, и функциональнее.

Отсутствие expression формы для switch делает проще компилятор, а язык наоборот, сложнее.

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

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

ARK>>Да, у вас все правильно, я ошибся.

AVK>В итоге ты идеально обосновал "пользу" индекса, начинающегося с 1

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

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


C>>Уродливо. Лучше всего у Питона:
C>>d = e if a==b else f

_NN>А еще лучше у сами знаете когоNemerle: :)
_NN>d = if (a == b) e else f;

Неправда, Питон нагляднее разделяет операнды.

do_something(value1 if condition else value2)
do_something(if(condition) value1 else value2)

особенно в ситуациях вроде

//                                ↓              ↓ границы отлично видно

do_something(q(value1a) + value1b if f(g(), h()) else value2)
do_something(if(f(g(), h())) q(value1a) + value1b else value2)

//                          ↑ а эта бросается в глаза?

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

ARK>Ничего подобного. Это перевод из одной системы в другую, а не свойство другой системы как таковой. При обратной трансляции вероятность ошибиться ровно такая же.
Хотелось бы обратить внимание на то, что в С, С++, С#, Java никакой "обратной трансляции" не нужно.
Просто сделал x mod len — и вот тебе индекс.

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

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

ARK>>Ничего подобного. Это перевод из одной системы в другую, а не свойство другой системы как таковой. При обратной трансляции вероятность ошибиться ровно такая же.
S>Хотелось бы обратить внимание на то, что в С, С++, С#, Java никакой "обратной трансляции" не нужно.
S>Просто сделал x mod len — и вот тебе индекс.

Спасибо, конечно, но индекс тут ни при чем, я говорил про другое. Про вероятность ошибки при трансляции кода из одной "системы индексации" в другую (что это за код — не важно).

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

ARK>Спасибо, конечно, но индекс тут ни при чем, я говорил про другое. Про вероятность ошибки при трансляции кода из одной "системы индексации" в другую (что это за код — не важно).
Вы, похоже, не понимаете, о чём речь.
Сама по себе трансляция — тривиальна; в приличных языках её можно отловить путём введения типизации на индексах.
Проблема индексации с единицы — в том, что безо всякой трансляции она провоцирует ошибки.
Арифметика таких индексов беспричинно сложна. Вам привели банальный пример, в котором нет никакой трансляции, а просто нужно обращаться к элементам массива "по кругу". И уже в нём паскалевская арифметика провоцирует ошибки.