А вот самый кавайный цикл, который я видел: хоть с предусловием, хоть с постусловием, да ещё и выход не по Break, а в труЪ структурном стайле программирования.
нет. ваше определение сахара отличается от общепринятого. http://www.haskell.org/haskellwiki/Syntactic_sugar http://en.wikipedia.org/wiki/Syntactic_sugar сахар не обязательно является урезанной версией другой фичи языка. сахар это фича которая может быть записана другими менее читабельными (красивыми, удобными) фичами, и при этом сахар не увеличивает мощность языка. так вот исторически сначала было { int x = 0; while (x != N) { ...; ++x; } } а потом ввели сахар в виде for(; нет. точно так же можно утверждать что без виртуальных методов нельзя использовать ООП. структурное программирование (СП) это парадигма, и она как любая парадигма не зависит от языковых средств. СП можно реализовать и с помощью if+goto (или jxx\jmp) если придерживаться правил СП я отношусь к людям считающим что термин синтаксический сахар часто используется не к месту. в рамках reference конкретного языка, можно сказать что "в версии 1.1 введена фича X которая является сахаром", но это только для конкретного языка, и только если это действительно сахар. говорить "Запись циклов типа 'for i in [1..10]' называется syntactic sugar -- синтаксический сахар" без указания языка некорректно. Потому что существует (может существовать) язык Х в котором for in не является сахаром. Более того, понятие мощности языка очень расплывчато, потому что читабельность и "писательность" часто имеют большое значение. Мы можем сказать что если без фичи X нельзя сделать того-то, то наличие этой фичи влияет на мощность языка. Так вот например в С++ for(; может влиять на мощность языка, потому что при создании некоторых DSL важно что for(; statement; создает область видимости без использования фигурных скобок - это позволяет писать макросы типа YIELD для coroutines.
GoldFinch А вы считаете, что for(;a<b более читабельна, чем while(a<b)? Я где-то говорил что нельзя программировать структурно, без структурных конструкций? Я использовал слово "загоняют". И не случайно. Ооо... Как я ненавижу формалистов и прочих бюрократов с буквоедами. Хорошо! Вы правы. Ваш авторитет непререкаем. И вам +10 к ЧСВ.
Wizard109 угу, и на чём писали. CyberManiac Компилятор/интерпретатор пусть обрабатывает как написано . ок, пусть будет: Code (Text): Fucktion WHEN MyVar ELSE Function SadKo с perl некогда разбираться. смотрел пайтон, весь синтаксис на день не прочитаешь... но близко к пониманию.
SEC70R_VA Так у множеств в Паскале/Delphi для элементов нет произвольно определяемого порядка следования, физически это просто битовая карта. Ну и совершенно искусственное ограничение на 256 элементов - это ещё больше мешает жить, ибо set of WideChar ну очень хочется.
Ну так и нефиг тогда флудерастию разводить. Читабельность исходников напрямую зависит от их оформления. Если вы араб и читаете справа налево - то это лично ваши проблемы, запилите свой компилятор со своим синтаксисом и набором инструкций. Важно не только удобство, но и однозначность трактования инструкций. Вот попробуйте определить, какие значения запишут самые различные компилеры в переменную j: Code (Text): int i=5; int j = ++i + ++i;
SEC70R_VA asm, с, с++, с#, Delphi, php, perl, java Возможно Брэйнфака и Лиспа вопрос о "читабельности" не касается, ибо это полный нимд* но для приведенных языков - абсолютно справедливо.
CyberManiac включите воображение SadKo кем бы я ни был, читабельность и понимание исходников зависит не только от написавшего код, но и от выбора языка программирования. предлагаете Сиплюсплюс чтоле? например, так можно было бы реализовать CASE, причем масштабируемо от конструкции WHEN, заменяющую IF...THEN... Code (Text): proc1 WHEN x=0 ELSE proc2 WHEN x=1 ELSE proc3 WHEN x=2
SEC70R_VA > кем бы я ни был, читабельность и понимание исходников зависит > не только от написавшего код, но и от выбора языка программирования. на любом языке программирования можно написать кошмарный код, который нужно разгадывать как ребус. на любом языке программирования можно писать понятно. даже на асме.
SEC70R_VA > Почему в классических языках программировании (в императивных в основном), > вместо, например x:=10 THEN y=1 принято писать IF y=1 THEN x:=10. наверное, потому что конструкция "если -- то" не только логична, но и совпадает с порядком выполнения инструкций ЦП. попробуйте выполнить такую задачку "СКАЗАТЬ пока-пока ЕСЛИ на стрелках два часа". какая будет последовательность ваших действий? 1) посмотреть на часы 2) если не два часа то (4) 3) сказать "кря" 4) ... хотя можно так: 1) сказать "кря" 2) посмотреть на часы 3) если два часа, то (5) 4) откат транзакции 5) ... > ИМХО, {...} FOR i:=[1..10] гораздо читабельней и понятней, > чем FOR i:=0 TO 10 DO {...}. опять же, при входе в цикл i неопределена. это раз. тогда уже for i in [1..10]. хотя for i:=[1..10] хорошо подходит для параллельного программирования и поддерживается достаточно широко. тем же питоном. и смысл такой конструкции (правда, в питоне синтаксис несколько иной) в том, что выполнить { ... } можно при разных значениях i на разных процах одновременно. > Эти префиксы отвлекают от понимания смысла программы. ну в питоне вообще минималисты: 'for x in y: print y[x]' предлагаете что ли писать 'print y[x]: for x in y' -- так у меня крыша поедет. > Может быть такой язык программирования уже есть? циклы с пост-условием есть во всех языках (ну вроде бы во всех).
Батенька, такого даже в SQL и PL/SQL нет. Разве что в перле: Code (Text): print "you are Mooduck!\n" if (lc $ARGV[0] eq 'mooduck'); Но за такой код убивать надо, особенно когда condition прячется где-то там за правым краем экрана.
SadKo > Но за такой код убивать надо, особенно когда condition прячется где-то там за правым краем экрана. убивать. потому что в любом языке можно создать конструкции типа: f = {proc1:0, proc2:1, proc3:2} и дальше f[x](); а в данном частном случае, даже еще проще: [proc1, proc2, proc3][x](); оно и понятнее и работает быстрее. и править проще при необходимости. в принципе, если извратится, то идею ТС можно записать на синтаксисе имеющихся языков. объявляем анонимную функу в {} и дальше вызываем ее если выполняется некоторое условие. так, кстати, иногда и поступают. но очень редко. ибо телегу впереди лошади все-таки не ставят
kaspersky утверждение верно когда _пишешь_ код; а когда _читаешь_ исходники (даже с комментами), поток инструкций удобней запоминать если они идут подряд, и условия(циклы тоже), налагаемые на выполнение инструкций главного потока программы не отвлекают. т.е. в начале каждой строки должно идти _то_что_делает_программа_ в рамках задачи, а не в рамках _реализации_ этой задачи. наверное, макросами можно сделать такое. SadKo 1920х1080 иметь надо .
SEC70R_VA Вы действительно убеждены, что это легче читать ??? Code (Text): proc1 WHEN x=0 ELSE proc2 WHEN x=1 ELSE proc3 WHEN x=2 Вопрос без намека на издевательство: а на чем вы писали, коли так привыкли к этому изврату ?
Хорошо, когда только x:=10, а если чуть более сложное? Что, любую вложенность больше двух-трех операций выполнять в виде отдельной процедуры? Даже если и удастся избежать накладных расходов вызова и передачи параметров за счет инлайн-функций/процедур, то анализировать такой код заколебешься - для большинства таких микропоследовательностей не удастся придумать само за себя говорящее название процедуры/функции, придется отвлекаться на внутренности таких микропроцедур - стек в голове переполнится (у нормального человека величина стека на-все-про-все - 7+/-2 недетализированных сущностей). Наверное самое оптимальное - писать/просматривать программы не в текстовом редакторе, а в чем-то подобном просмотрщику XML-контента, давая возможность анализирующему скрывать/раскрывать внутренние блоки управляющих конструкций. При этом надо обязать программеров давать таким блокам более-менее осмысленное название для отображения в свернутом виде - фактически это будет некое принудительное комментирование программы, которого избежать будет очень сложно. В качестве вкусности от такого представления программы неплохо было бы иметь возможность раскрывать по месту не только реально там находящиеся блоки у правляющих конструкций, но и содержимое вызываемых процедур/функций (конечно как-то выделяя такое представление, например цветом, чтоб не путаловсь с реально пристутсвующим по месту кодом). А может быть такой велосипед уже изобретен, знает кто-нибудь?
Dmitry_Milk Ну мне в особо запущенных случаях помогает стандартная Visual Studio c возможностью Outline. т.е. скрываешь части кода которые тебе не важны/формируешь более - менее удобную структуру для навигации. Не очень удобно, но гораздо легче просматривать километровый кодес состоящий из кучи вложенных if 'ов. З.Ы. Кстати где-то видел нечто "навигатор по коду" который отображает в ListBox'е слева как раз вложенные условия с комментариями к ним, циклы и.т.п. Мне не показался удобным, не люблю тыцкать крысой по всему монитору, а работать при помощи кейборда с ним дико неудобно, посему не запоминал. Но почему - то кажется что много их...
SadKo Одна из причин по которой так и не перейду на Linux - отсутствие чего-то что вообще можно было бы назвать IDE ( Eclipse не предлагать ! ), нормального отладчика и мегатонны такого кода... грхм... о котором в этом топике и идет речь. З.Ы. Хотя как утверждают некоторые товарищи из Vi можно слепить все что хочешь. Увы, я не слепил
