02.10.2012 13:20, dimgel пишет: > > ...вместо '||' — 'or', вместо '{' и '}' — 'begin' и 'end', вместо > while(...) — goto 10.
А самое смешное, что ТУПО запрещать это кодерам!!!!!!!!!!!!!!!
Только не говорите что СЛОЖНО реализовать поддержку ключевых слов begin
и end, а также and, or, not, = (вместо ==) и GOTO. Это банально улучшает
ЧИТАЕМОСТЬ кода!!!
И ещё момент — почему например анонимному классу нельзя без применения
"универсального интерфейса" передать параметр в конструкторе? Хотя при
последующей декомпиляции оказывается, что ИМЕННО ЭТО код и делает.
Аналогично GOTO. Если хоть раз пробовали развязать декомпиленый код
после обфускации, то ОЧЕНЬ СИЛЬНО не хватает именно связок GOTO, которые
чётко дают понять куда так сильно стремится очередная ветка кода. Потому
что в байт-коде оказываются именно эти самые GOTO.
Здравствуйте, ResidentR6, Вы писали:
RR>А самое смешное, что ТУПО запрещать это кодерам!!!!!!!!!!!!!!! RR>Только не говорите что СЛОЖНО реализовать поддержку ключевых слов begin RR>и end, а также and, or, not, = (вместо ==) и GOTO. Это банально улучшает RR>ЧИТАЕМОСТЬ кода!!!
Читаемость кем?
Обойтись без скобок за счёт уровней отступа я бы ещё понял.
RR>И ещё момент — почему например анонимному классу нельзя без применения RR>"универсального интерфейса" передать параметр в конструкторе? Хотя при RR>последующей декомпиляции оказывается, что ИМЕННО ЭТО код и делает.
То есть?
final int param=42;
new Thread(new Runnable() {
public void run() { System.out.println(param); }
}).start();
Всё работает.
RR>Аналогично GOTO. Если хоть раз пробовали развязать декомпиленый код
Мы как-то предпочитаем язык, который предназначен для работы с кодом, а не декомпиляции.
Я и не говорю что нельзя приспособиться. А лишь о том, что это некошерно
приспосабливаться под софт, когда можно приспособить сам софт.
Пунктуация знаками однозначно хуже чем словами. Потому что человеку
проще думать словами, а не краказябликами.
Верхом подобного ханженства я считаю регулярные выражения. Да, они
прекрасно работают. Но почему, в честь какого Ктулху, я на языке
высокого уровня должен писать сие непонятными значками? Почему нельзя
написать то же самое понятным языком, на уровне логики "если",
"повторяется", "после"...
Или можно? Кстати, никто не в курсе, есть ли инструмент создания
регулярных выражений? Чтобы в коде написать читаемо, а потом оно уже
само преобразовывалось.
Здравствуйте, ResidentR6, Вы писали:
RR>Пунктуация знаками однозначно хуже чем словами. Потому что человеку RR>проще думать словами, а не краказябликами.
Мне, лично, проще читать код с кракозябрами. Так как они выделяются на фоне остального текста.
RR>Верхом подобного ханженства я считаю регулярные выражения. Да, они RR>прекрасно работают. Но почему, в честь какого Ктулху, я на языке RR>высокого уровня должен писать сие непонятными значками? Почему нельзя RR>написать то же самое понятным языком, на уровне логики "если", RR>"повторяется", "после"...
Потому, что регэкспы задумывались для компактной записи регулярных выражений:
И ".*str[^A]" читается сильно лучше, чем "<any_symbol><kleene_star>str<one_of>(not<set-of>A)"
Здравствуйте, ResidentR6, Вы писали:
RR>А самое смешное, что ТУПО запрещать это кодерам!!!!!!!!!!!!!!! RR>Только не говорите что СЛОЖНО реализовать поддержку ключевых слов begin RR>и end, а также and, or, not, = (вместо ==) и GOTO. Это банально улучшает RR>ЧИТАЕМОСТЬ кода!!!
Говорите, = вместо == читаемость улучшает?
if (a = b = c){
}
Что-нибудь можете сказать о том, что тут происходит? Присваивания? Сравнения? Типы у a, b, c одинаковые хотя бы?
Здравствуйте, Skipy, Вы писали:
S>Говорите, = вместо == читаемость улучшает?
S>
if (a = b = c){
S>}
S>Что-нибудь можете сказать о том, что тут происходит? Присваивания? Сравнения? Типы у a, b, c одинаковые хотя бы?
Гы, щас тоже ляпну. Вообще, как по мне, я бы вообще запретил присваивания внутри if. Из-за этого вот стремления к супер-через сокращениям этот вот бардак и выходит. Примерно как многие любят ради избавления от повторящихся кусков кода длиной в 2-3 строчки плодить запутанные иерархии классов.
Здравствуйте, ResidentR6, Вы писали:
RR>Пунктуация знаками однозначно хуже чем словами. Потому что человеку RR>проще думать словами, а не краказябликами.
Скажите это китайцам. А вообще, совершенно необоснованное высказывание. Ткните мне на результаты экспериментов, доказывающих это.
RR>Или можно? Кстати, никто не в курсе, есть ли инструмент создания RR>регулярных выражений? Чтобы в коде написать читаемо, а потом оно уже RR>само преобразовывалось.
Здравствуйте, ResidentR6, Вы писали:
>> >> ...вместо '||' — 'or', вместо '{' и '}' — 'begin' и 'end', вместо >> while(...) — goto 10.
RR>А самое смешное, что ТУПО запрещать это кодерам!!!!!!!!!!!!!!! RR>Только не говорите что СЛОЖНО реализовать поддержку ключевых слов begin RR>и end, а также and, or, not, = (вместо ==) и GOTO. Это банально улучшает RR>ЧИТАЕМОСТЬ кода!!!
Сложно. Это поломает legacy-код, в котором есть идентификаторы begin, end, and, or, not. А ещё слово begin — лишнее. Если уж делать такие словесные блоки, то следует делать их как в ruby, т.е. любая конструкция вроде if, for автоматически порождает блок, который надо закрывать end'ом.
RR>Аналогично GOTO. Если хоть раз пробовали развязать декомпиленый код RR>после обфускации, то ОЧЕНЬ СИЛЬНО не хватает именно связок GOTO, которые RR>чётко дают понять куда так сильно стремится очередная ветка кода. Потому RR>что в байт-коде оказываются именно эти самые GOTO.
Если внимательно читать спецификацию Java, то можно заметить, что с помощью break можно выйти из любого блока. В принципе, можно было бы даже без этого обойтись, применив конструкцию do { ... } while (false); Таким образом, правильно подобрав начала блоков (можно все начала оттянуть хоть бы и к началу текущего цикла или к началу программы, если цель GOTO находится вне циклов; но так, разумеется, не слишком читабельно), можно запросто эмулировать goto. Единственные два ограничения (невозможность прыгнуть внутрь цикла или назад) запросто обходятся переупорядочиванием байт-кода. Что самое интересное, потом эту последовательность блоков гораздо проще трансформировать в читабельные if'ы, чем просто goto. Это я говорю как человек, писавший декомпилятор JVM.
Здравствуйте, AlexRK, Вы писали:
ARK>И желательно выражаться другим знаком, например тем же := .
А еще массивы должны по умолчанию индексироваться с 1, а не с 0. Про BEGIN/END уже написали. Ну и для полной благодати расширение у файлов исходников сделать *.pas
Здравствуйте, rusted, Вы писали:
R>А еще массивы должны по умолчанию индексироваться с 1, а не с 0.
По моему скромному мнению, массивы в ЯП общего назначения должны индексироваться исключительно с 1 (без возможности выбора другого индекса).
R>Про BEGIN/END уже написали.
Вместо кривых скобок? Согласен. Но лучше в нижнем регистре.
R>Ну и для полной благодати расширение у файлов исходников сделать *.pas
Здравствуйте, ResidentR6, Вы писали:
RR>Или можно? Кстати, никто не в курсе, есть ли инструмент создания RR>регулярных выражений? Чтобы в коде написать читаемо, а потом оно уже RR>само преобразовывалось.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Cyberax, Вы писали:
C>>И ".*str[^A]" читается сильно лучше, чем "<any_symbol><kleene_star>str<one_of>(not<set-of>A)"
KV>Клини стар, Клини суперстар, ага. KV>kleene_asterisk или kleene_clojure все-таки
Замыкание Клини — операция, обозначаемая символом * Правильным названием этого символа является "астериск", а "звезда" — его разговорный вариант. Примерно также, как @ — это "at", а не "собака".
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, RomikT, Вы писали:
KV>Замыкание Клини — операция, обозначаемая символом * Правильным названием этого символа является "астериск", а "звезда" — его разговорный вариант. Примерно также, как @ — это "at", а не "собака".
То, что символ "*" называется asterisk, ещё не означает что замыкание Клини называется так же.
Гугл, конечно, не истина в последней истанции, но всё же показателен: "Kleene star" — about 44,000 results "Kleene asterisk" — 3 results
Здравствуйте, AlexRK, Вы писали:
R>>А еще массивы должны по умолчанию индексироваться с 1, а не с 0. ARK>По моему скромному мнению, массивы в ЯП общего назначения должны индексироваться исключительно с 1 (без возможности выбора другого индекса).
Повбывав бы.
ARK>По моему скромному мнению, массивы в ЯП общего назначения должны индексироваться исключительно с 1 (без возможности выбора другого индекса).
Ну и для твёрдого, железного, доказательства что идеальный индекс это с 1 и без вариантов, прошу сорец какой-нить математической хрени, работающей со степенями двойки. Вроде преобразования фурье, блочного шифрования, или аудио/видео кодека. А мы вместе поулыбаемся.
Здравствуйте, hi_octane, Вы писали:
ARK>>По моему скромному мнению, массивы в ЯП общего назначения должны индексироваться исключительно с 1 (без возможности выбора другого индекса). _>Ну и для твёрдого, железного, доказательства что идеальный индекс это с 1 и без вариантов, прошу сорец какой-нить математической хрени, работающей со степенями двойки. Вроде преобразования фурье, блочного шифрования, или аудио/видео кодека. А мы вместе поулыбаемся.
Модульная арифметика тоже очень неплохо сюда относится.
R>>А еще массивы должны по умолчанию индексироваться с 1, а не с 0.
ARK>По моему скромному мнению, массивы в ЯП общего назначения должны индексироваться исключительно с 1 (без возможности выбора другого индекса).
Ага. Чтобы сишники(а заодно и использующие unsafe, а заодно и те, кто работает с файлами и прочими системными вещами, заодно писатели компиляторов и еще куча людей) повесились к чертям.
Я вот вроде джавист, но категорически против начала с единицы. Геморроя на ровном месте много, а толку ровно ноль.
R>>Про BEGIN/END уже написали.
ARK>Вместо кривых скобок? Согласен. Но лучше в нижнем регистре.
Дада, давайте превратим код в нечитабельную хрень! Вперед!
Символы тем и хороши, что моментально на глаз отличаются от слов. Даже в однострочных конструкциях. А ИДЕ пофигу, чего автоматом нагенерить — хоть иероглифы. Все равно руками никто это никогда не пишет.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, hi_octane, Вы писали:
_>Ну и для твёрдого, железного, доказательства что идеальный индекс это с 1 и без вариантов, прошу сорец какой-нить математической хрени, работающей со степенями двойки. Вроде преобразования фурье, блочного шифрования, или аудио/видео кодека. А мы вместе поулыбаемся.
Низкоуровневые/системные вещи можно писать на С. "Математическую хрень" на фортране или специальном DSL.
Здравствуйте, Eugeny__, Вы писали:
E__>Ага. Чтобы сишники(а заодно и использующие unsafe, а заодно и те, кто работает с файлами и прочими системными вещами, заодно писатели компиляторов и еще куча людей) повесились к чертям.
Все эти вещи на ЯП общего назначения, ИМХО, делать не стоит.
E__>Я вот вроде джавист, но категорически против начала с единицы. Геморроя на ровном месте много, а толку ровно ноль.
Хм, ну а я не вижу геморроя. Если что, сейчас пишу на С#.
E__>Дада, давайте превратим код в нечитабельную хрень! Вперед!
E__>Символы тем и хороши, что моментально на глаз отличаются от слов. Даже в однострочных конструкциях. А ИДЕ пофигу, чего автоматом нагенерить — хоть иероглифы. Все равно руками никто это никогда не пишет.
Здравствуйте, AlexRK, Вы писали:
E__>>Ага. Чтобы сишники(а заодно и использующие unsafe, а заодно и те, кто работает с файлами и прочими системными вещами, заодно писатели компиляторов и еще куча людей) повесились к чертям.
ARK>Все эти вещи на ЯП общего назначения, ИМХО, делать не стоит.
А что же тогда на них писать-то?
E__>>Я вот вроде джавист, но категорически против начала с единицы. Геморроя на ровном месте много, а толку ровно ноль.
ARK>Хм, ну а я не вижу геморроя. Если что, сейчас пишу на С#.
А что же не на VB# тогда?
E__>>Символы тем и хороши, что моментально на глаз отличаются от слов. Даже в однострочных конструкциях. А ИДЕ пофигу, чего автоматом нагенерить — хоть иероглифы. Все равно руками никто это никогда не пишет.
ARK>Зато символы от других символов не отличаются.
ARK>([](){})() — is now legal C++ (c)
Отошел на три метра. Отличаю прекрасно даже с этого расстояния, без какого-либо напряга мозга. Что я делаю не так?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>А что же тогда на них писать-то?
Эээ... ну все остальное, например. Вы считаете, что код фотошопа состоит исключительно из компиляторов, драйверов и преобразований Фурье?
E__>А что же не на VB# тогда?
У VB свои тараканы, тысячи их. Программисты на Basic умственно оболванены без надежды на исцеление (с)
Кроме того, язык выбираю не я.
E__>Отошел на три метра. Отличаю прекрасно даже с этого расстояния, без какого-либо напряга мозга. Что я делаю не так?
Я рад за вас. А я прекрасно слова друг от друга отличаю. Что я делаю не так?
Здравствуйте, AlexRK, Вы писали:
E__>>А что же тогда на них писать-то?
ARK>Эээ... ну все остальное, например. Вы считаете, что код фотошопа состоит исключительно из компиляторов, драйверов и преобразований Фурье?
Не знаю, конечно. Но мне отчего-то кажется, что там математики и работы с адресами памяти огромное количество. Ибо преобразование изображений — это сплошная математика. А трансляция адресов на единицу назад для обработки каждого пикселя при обработке — космический оверхед по производительности. Без единого на то основания.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Не знаю, конечно. Но мне отчего-то кажется, что там математики и работы с адресами памяти огромное количество. Ибо преобразование изображений — это сплошная математика. А трансляция адресов на единицу назад для обработки каждого пикселя при обработке — космический оверхед по производительности. Без единого на то основания.
Возможно вы правы. Я всего лишь высказал свое мнение, на комитет С++ или Хейлсберга я влияния не имею, так что сильно беспокоиться нет причин.
Хотя насчет математики — я не вижу чего-то принципиального, что требовало бы индексации массивов именно с нуля. Это остатки тяжелого системного прошлого, ИМХО. Хороший компилятор должен статически выполнить все близкие к железу оптимизации.
Здравствуйте, AlexRK, Вы писали:
ARK>Хотя насчет математики — я не вижу чего-то принципиального, что требовало бы индексации массивов именно с нуля. Это остатки тяжелого системного прошлого, ИМХО. Хороший компилятор должен статически выполнить все близкие к железу оптимизации.
К примеру, организация кольцевого буфера: x[num % x.length]. Всё красиво и понятно. На паскалеподобной гадости будет: "x((num-1) mod x.length +1)" — офигеть как красиво. И это ещё цветочки.
ARK>Низкоуровневые/системные вещи можно писать на С. "Математическую хрень" на фортране или специальном DSL.
То что я перечислил это низкоуровневые вещи, или системные? Какие преимущества имеет индексация с 1, которые перевешивают неудобства при решении целых классов реальных задач?
Здравствуйте, 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 не привел ни одного логичного довода, почему индексирование с единицы — это хорошо. Кроме того, что ему бы так хотелось.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>При этом AlexRK не привел ни одного логичного довода, почему индексирование с единицы — это хорошо. Кроме того, что ему бы так хотелось.
Лично я вообще удивлён, что эту ветку перенесли в "философию", а не в "ксв". Видно ж, что троллизм.
Добавлю: читаемость кода начинающим, и читаемость кода экспертом — это разные читаемости.
Соответственно и синтаксис надо сделать настраиваемым в ИДЕ...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
ARK>"преобразования фурье, блочного шифрования, или аудио/видео кодека"? ARK>Однозначно низкоуровневые.
Ну обычно "низкоуровневые" это имеется ввиду ближе к железу. Типа там драйвера, работа с портами и т.п. А то что я перечислил — это скорее библиотечные алгоритмы. И тут получается что ты предлагаешь сделать в языке общего назначения индексацию неудобную для создания на этом языке библиотечных алгоритмов. А их ведь писать надо. Получается на другом языке. А кто должен будет соединять индексацию библиотек и языков их использующих? Вот надо передать индекс в библиотеку, кто должен делать в правильных местах +1 и -1? Библиотека? Так ей не положено — использовать её могут из любого языка. Программист на предлагаемом языке с индексацией с 1? Так ему геморрой.
И будет ли людям удобно переключаться с одного языка на другой, с разными правилами индексации, в пределах одного проекта? Часто же одновременно делаются и библиотечные алгоритмы и прикладной код. Или смотрешь в отладчике на индекс, и думаешь "а с 1 он или с 0?". Как быстро коллектив решит забить и всё писать на языке пригодном и для разработки и того и другого?
_>>Какие преимущества имеет индексация с 1, которые перевешивают неудобства при решении целых классов реальных задач?
ARK>Отсутствие путаницы (если запретить менять индекс) и близость к реальному миру. Люди перечисляют вещи с единицы, а не с нуля.
Люди может и перечесляют с 1, но мы то не людей программируем.
Здравствуйте, 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]. По-моему, отлично выглядит, адского криминала нет, тем более, что кольцевые буферы это тоже весьма специфическая вещь.
Неа. У меня правильно написано было.
Здравствуйте, dimgel, Вы писали:
D>О господи, ещё и у if-а две формы теперь! А вот знаете, можно вызов любой функции написать и как статемент, и как выражение:
D>f(); // statement D>x = f() + 1; // выражение
В моем понимании первое выражение — это процедура, а не функция. Нечто с побочным эффектом.
В Eiffel так и сделано, и это правильно, ИМХО.
Так что не "любой функции", а "любой функции в C++ или Java".
D>Да и вообще во всех языках, какие я помню, в БНФ присутствует: D>statement := expression | ...
Ну, далеко не каждый statement содержит expression.
Вызов процедуры — не содержит.
D>Чем же if хуже, что вы его так обижаете?
Здравствуйте, 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". Поэтому и запрещать ничего не надо.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, AlexRK, Вы писали:
ARK>>Да, у вас все правильно, я ошибся.
AVK>В итоге ты идеально обосновал "пользу" индекса, начинающегося с 1
Ничего подобного. Это перевод из одной системы в другую, а не свойство другой системы как таковой. При обратной трансляции вероятность ошибиться ровно такая же.
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>Спасибо, конечно, но индекс тут ни при чем, я говорил про другое. Про вероятность ошибки при трансляции кода из одной "системы индексации" в другую (что это за код — не важно).
Вы, похоже, не понимаете, о чём речь.
Сама по себе трансляция — тривиальна; в приличных языках её можно отловить путём введения типизации на индексах.
Проблема индексации с единицы — в том, что безо всякой трансляции она провоцирует ошибки.
Арифметика таких индексов беспричинно сложна. Вам привели банальный пример, в котором нет никакой трансляции, а просто нужно обращаться к элементам массива "по кругу". И уже в нём паскалевская арифметика провоцирует ошибки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Сама по себе трансляция — тривиальна; в приличных языках её можно отловить путём введения типизации на индексах.
Хм. В каких же, например?
Явно не в промышленных, в которых трансляция уже не так тривиальна.
S>Проблема индексации с единицы — в том, что безо всякой трансляции она провоцирует ошибки.
Довольно сильное утверждение. Обосновать можете?
S>Арифметика таких индексов беспричинно сложна. Вам привели банальный пример, в котором нет никакой трансляции, а просто нужно обращаться к элементам массива "по кругу". И уже в нём паскалевская арифметика провоцирует ошибки.
Ну, один пример — это ни о чем. К тому же пример сильно специфический. Я вот за последние годы ни разу кольцевых буферов не организовывал (сейчас занимаюсь разработкой геоинформационной системы). Если речь о написании драйверов и менеджеров памяти — тут применяйте Ц, мне не жалко.
Здравствуйте, AlexRK, Вы писали:
ARK>Ну, один пример — это ни о чем. К тому же пример сильно специфический. Я вот за последние годы ни разу кольцевых буферов не организовывал (сейчас занимаюсь разработкой геоинформационной системы). Если речь о написании драйверов и менеджеров памяти — тут применяйте Ц, мне не жалко.
Блин, у меня подобного кода тонны в прикладных приложениях. Или возьмём для примера такую ситуацию — буфер разделён на сегменты по 512 байт. Нужно рассчитать смещение в байтах N-ного байта M-ного блока от начала буфера.
В С: offset = M*512 + N
В паскалеподобных: offset := (M-1)*512 + N-1
Здравствуйте, AlexRK, Вы писали:
ARK>Хм. В каких же, например? ARK>Явно не в промышленных, в которых трансляция уже не так тривиальна.
В любых, где есть перегрузка операций. Т.е. в C++ и C#.
Применяем паттерн Декоратор — и вперёд, на танки. ARK>Довольно сильное утверждение. Обосновать можете?
Вы же только что его сами же и продемонстрировали.
ARK>Ну, один пример — это ни о чем. К тому же пример сильно специфический. Я вот за последние годы ни разу кольцевых буферов не организовывал (сейчас занимаюсь разработкой геоинформационной системы). Если речь о написании драйверов и менеджеров памяти — тут применяйте Ц, мне не жалко.
Ну речь же не только о кольцевых буферах. Уложить, к примеру, прямоугольную матрицу в линейный массив — опять нужно ((x-1)*h)+y-1. И так далее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В любых, где есть перегрузка операций. Т.е. в C++ и C#. S>Применяем паттерн Декоратор — и вперёд, на танки.
А, вон что.
Но я говорил не об этом, а о ручной трансляции "на бумажке" — где, собственно, и ошибся.
S>Вы же только что его сами же и продемонстрировали.
"Мамой клянусь, треугольник" (с)
S>Ну речь же не только о кольцевых буферах. Уложить, к примеру, прямоугольную матрицу в линейный массив — опять нужно ((x-1)*h)+y-1. И так далее.
Тут как раз вопрос в том, много ли этих "и так далее". У меня такой статистики нет, поэтому утверждать, что я прав, не берусь.
Здравствуйте, AlexRK, Вы писали:
C>>Блин, у меня подобного кода тонны в прикладных приложениях. ARK>Не срача ради, а токмо научного интереса для: какие, например, у вас прикладные приложения и зачем там кольцевые буфера?
Такой код у меня во вполне обычном учётном приложении, в рисовании специальных графических виджетов.
А ещё я занимаюсь генетическими ассемблерами — там подобный код примерно 100% всего кода.
Здравствуйте, LaptevVV, Вы писали:
LVV>Добавлю: читаемость кода начинающим, и читаемость кода экспертом — это разные читаемости. LVV>Соответственно и синтаксис надо сделать настраиваемым в ИДЕ...
Ага, таким образом окончательно убив читаемость кода. Спасибо, не надо!
Здравствуйте, dolor, Вы писали:
D>а, хотел бы вместо && писать 'and'
Я уже так пишу, на Python'е. Все эти &&, || и прочие штуки, действительно анахронизмы в XXI веке. Популярность Python'а (не смотря на его тормознутость и прочие минусы) показала на практике всю важность синтаксиса языка программирования. В принципе, это есть пруф того, что не нужно гоняться за C-like синтаксисом в надежде на то, что C/C++/Java/C# программисты перейдут на ваш язык из-за того, что синтаксис им будет привычен.
Здравствуйте, iLikeCookies, Вы писали:
LVV>>Добавлю: читаемость кода начинающим, и читаемость кода экспертом — это разные читаемости. LVV>>Соответственно и синтаксис надо сделать настраиваемым в ИДЕ...
LC>Ага, таким образом окончательно убив читаемость кода. Спасибо, не надо!
Предполагается, что начинающие и эксперты могут одинаково хорошо читать код ?
Здравствуйте, Ikemefula, Вы писали:
I>Предполагается, что начинающие и эксперты могут одинаково хорошо читать код ?
Предполагается, что будет создан синтаксис одинаково хороший и для начинающих и для опытных товарищей. И еще предполагается, что возможность плодить бесконечное количество разных настроенных синтаксисов приведет к хаосу и разрушениям. И последнее, язык программирования, это такой же язык общения, но между программистами. Если каждый программист будет говорить на своем языке, настроенном под себя, другие вряд ли его поймут и захотят с ним поиграть в песочнице.
Здравствуйте, iLikeCookies, Вы писали:
LC>Здравствуйте, Ikemefula, Вы писали:
I>>Предполагается, что начинающие и эксперты могут одинаково хорошо читать код ?
LC>Предполагается, что будет создан синтаксис одинаково хороший и для начинающих и для опытных товарищей.
Такого не бывает. Любой синтаксис будет лучше понятен опытным товарищам. Любая терминология лучше понятна людям с опытом.
>И еще предполагается, что возможность плодить бесконечное количество разных настроенных синтаксисов приведет к хаосу и разрушениям. И последнее, язык программирования, это такой же язык общения, но между программистами. Если каждый программист будет говорить на своем языке, настроенном под себя, другие вряд ли его поймут и захотят с ним поиграть в песочнице.
То есть, ты выступаешь за естественный язык, вроде английского, русского ?
Здравствуйте, ResidentR6, Вы писали:
RR>Только не говорите что СЛОЖНО реализовать поддержку ключевых слов begin RR>и end, а также and, or, not, = (вместо ==) и GOTO. Это банально улучшает RR>ЧИТАЕМОСТЬ кода!!!
Здравствуйте, AlexRK, Вы писали:
ARK>Низкоуровневые/системные вещи можно писать на С. "Математическую хрень" на фортране или специальном DSL.
Ну воот, начинается юление.
Здравствуйте, AlexRK, Вы писали:
R>>Про BEGIN/END уже написали. ARK>Вместо кривых скобок? Согласен. Но лучше в нижнем регистре. R>>Ну и для полной благодати расширение у файлов исходников сделать *.pas ARK>Это пофиг.
Рекомендую обратиться к ABAP, вот где раздолье.
1. Никаких скобочек. Только суровые IF...ENDIF. DEFINITION...END-OF-DEFINITION.
2. Индексы с 1 (впрочем никаких массивов там нет, бугага)
3. Недавно лишь ввели оператор конкатации строк. Но можно польоваться старым добрым CONCATENATE x y z INTO w.
4. Никаких булевских переменных — это слишком усложняет код. Опять же, сейчас чистоту попортили и стало возможным писать IF x + y < z. (Раньше надо было объявить переменную, потом выполнить присвоение в нее суммы, и лишь потом использовать в условии).
...
7. PROFIT!!!
Я бы сказал что все споры по поводу and vs || бред полный.
Намного более важно рассмотреть "понимаемость структуры кода" в целом.
Для читаемости отдельного метода/класса достаточно соблюдать SRP.
