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

R>>А еще массивы должны по умолчанию индексироваться с 1, а не с 0.
ARK>По моему скромному мнению, массивы в ЯП общего назначения должны индексироваться исключительно с 1 (без возможности выбора другого индекса).
Повбывав бы.

ARK>По моему скромному мнению, массивы в ЯП общего назначения должны индексироваться исключительно с 1 (без возможности выбора другого индекса).

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

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

ARK>>По моему скромному мнению, массивы в ЯП общего назначения должны индексироваться исключительно с 1 (без возможности выбора другого индекса).
_>Ну и для твёрдого, железного, доказательства что идеальный индекс это с 1 и без вариантов, прошу сорец какой-нить математической хрени, работающей со степенями двойки. Вроде преобразования фурье, блочного шифрования, или аудио/видео кодека. А мы вместе поулыбаемся.
Модульная арифметика тоже очень неплохо сюда относится.

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


R>>А еще массивы должны по умолчанию индексироваться с 1, а не с 0.

ARK>По моему скромному мнению, массивы в ЯП общего назначения должны индексироваться исключительно с 1 (без возможности выбора другого индекса).

Ага. Чтобы сишники(а заодно и использующие unsafe, а заодно и те, кто работает с файлами и прочими системными вещами, заодно писатели компиляторов и еще куча людей) повесились к чертям.
Я вот вроде джавист, но категорически против начала с единицы. Геморроя на ровном месте много, а толку ровно ноль.

R>>Про BEGIN/END уже написали.

ARK>Вместо кривых скобок? Согласен. Но лучше в нижнем регистре.

Дада, давайте превратим код в нечитабельную хрень! Вперед!
Символы тем и хороши, что моментально на глаз отличаются от слов. Даже в однострочных конструкциях. А ИДЕ пофигу, чего автоматом нагенерить — хоть иероглифы. Все равно руками никто это никогда не пишет.

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

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

Низкоуровневые/системные вещи можно писать на С. "Математическую хрень" на фортране или специальном DSL.

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

E__>Ага. Чтобы сишники(а заодно и использующие unsafe, а заодно и те, кто работает с файлами и прочими системными вещами, заодно писатели компиляторов и еще куча людей) повесились к чертям.

Все эти вещи на ЯП общего назначения, ИМХО, делать не стоит.

E__>Я вот вроде джавист, но категорически против начала с единицы. Геморроя на ровном месте много, а толку ровно ноль.

Хм, ну а я не вижу геморроя. Если что, сейчас пишу на С#.

E__>Дада, давайте превратим код в нечитабельную хрень! Вперед!



E__>Символы тем и хороши, что моментально на глаз отличаются от слов. Даже в однострочных конструкциях. А ИДЕ пофигу, чего автоматом нагенерить — хоть иероглифы. Все равно руками никто это никогда не пишет.

Зато символы от других символов не отличаются.

([](){})() — is now legal C++ (c)

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

E__>>Ага. Чтобы сишники(а заодно и использующие unsafe, а заодно и те, кто работает с файлами и прочими системными вещами, заодно писатели компиляторов и еще куча людей) повесились к чертям.

ARK>Все эти вещи на ЯП общего назначения, ИМХО, делать не стоит.

А что же тогда на них писать-то?

E__>>Я вот вроде джавист, но категорически против начала с единицы. Геморроя на ровном месте много, а толку ровно ноль.

ARK>Хм, ну а я не вижу геморроя. Если что, сейчас пишу на С#.

А что же не на VB# тогда?

E__>>Символы тем и хороши, что моментально на глаз отличаются от слов. Даже в однострочных конструкциях. А ИДЕ пофигу, чего автоматом нагенерить — хоть иероглифы. Все равно руками никто это никогда не пишет.

ARK>Зато символы от других символов не отличаются.

ARK>([](){})() — is now legal C++ (c)

Отошел на три метра. Отличаю прекрасно даже с этого расстояния, без какого-либо напряга мозга. Что я делаю не так?

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

E__>А что же тогда на них писать-то?

Эээ... ну все остальное, например. Вы считаете, что код фотошопа состоит исключительно из компиляторов, драйверов и преобразований Фурье?

E__>А что же не на VB# тогда?

У VB свои тараканы, тысячи их. Программисты на Basic умственно оболванены без надежды на исцеление (с)
Кроме того, язык выбираю не я.

E__>Отошел на три метра. Отличаю прекрасно даже с этого расстояния, без какого-либо напряга мозга. Что я делаю не так?

Я рад за вас. А я прекрасно слова друг от друга отличаю. Что я делаю не так?

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

E__>>А что же тогда на них писать-то?

ARK>Эээ... ну все остальное, например. Вы считаете, что код фотошопа состоит исключительно из компиляторов, драйверов и преобразований Фурье?

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

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

E__>Не знаю, конечно. Но мне отчего-то кажется, что там математики и работы с адресами памяти огромное количество. Ибо преобразование изображений — это сплошная математика. А трансляция адресов на единицу назад для обработки каждого пикселя при обработке — космический оверхед по производительности. Без единого на то основания.

Возможно вы правы. Я всего лишь высказал свое мнение, на комитет С++ или Хейлсберга я влияния не имею, так что сильно беспокоиться нет причин.
Хотя насчет математики — я не вижу чего-то принципиального, что требовало бы индексации массивов именно с нуля. Это остатки тяжелого системного прошлого, ИМХО. Хороший компилятор должен статически выполнить все близкие к железу оптимизации.

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

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

ARK>Низкоуровневые/системные вещи можно писать на С. "Математическую хрень" на фортране или специальном DSL.

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

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

put a, (a plus b) div c End
put d, a xor uint32(-2) End

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

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

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

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

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

ARK>>Низкоуровневые/системные вещи можно писать на С. "Математическую хрень" на фортране или специальном DSL.

_>То что я перечислил это низкоуровневые вещи, или системные?

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

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

Отсутствие путаницы (если запретить менять индекс) и близость к реальному миру. Люди перечисляют вещи с единицы, а не с нуля.

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

RR>02.10.2012 13:20, dimgel пишет:
>>
>> ...вместо '||' — 'or', вместо '{' и '}' — 'begin' и 'end', вместо
>> while(...) — goto 10.


RR>А самое смешное, что ТУПО запрещать это кодерам!!!!!!!!!!!!!!!
RR>Только не говорите что СЛОЖНО реализовать поддержку ключевых слов begin
RR>и end, а также and, or, not, = (вместо ==) и GOTO. Это банально улучшает
RR>ЧИТАЕМОСТЬ кода!!!

Кому-то удобнее читать код с {} && ||, а кому-то — с begin, end, and, or. Но ИМХО, если используется IDE или редактор с подсветкой синтаксиса — без разницы.

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

Примеры:

{пример 1 на Паскале}
b := c;
if a = b then
    d := e;
else
    d := f;
end


{пример 2 на Паскале}
b:=c;if a=b then d:=e else d:=f end

// пример 1 на Си
b = c;
if (a == b)
    d = e;
else
    d = f;


// пример 2 на Си
if(a==(b=c)) d=e;else d=f;


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

Первый пример 1 на обеих языках читается лучше, чем пример 2 на любом языке. Пример 3 на Си читается труднее, чем пример 1, но для того, кто привык к таким конструкциям, проблемы не вызывает.

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

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

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

Да таких примеров можно сотни привести. Дьявол — он в мелочах.
При этом AlexRK не привел ни одного логичного довода, почему индексирование с единицы — это хорошо. Кроме того, что ему бы так хотелось.

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

E__>При этом AlexRK не привел ни одного логичного довода, почему индексирование с единицы — это хорошо. Кроме того, что ему бы так хотелось.

Лично я вообще удивлён, что эту ветку перенесли в "философию", а не в "ксв". Видно ж, что троллизм.

Добавлю: читаемость кода начинающим, и читаемость кода экспертом — это разные читаемости.
Соответственно и синтаксис надо сделать настраиваемым в ИДЕ...

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

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

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

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

ARK>Отсутствие путаницы (если запретить менять индекс) и близость к реальному миру. Люди перечисляют вещи с единицы, а не с нуля.

Люди может и перечесляют с 1, но мы то не людей программируем.