давайте пообсуждаем синтаксические особенности существующих языков, их преимущества и недостатки и попытаемся выработать синтаксис языка будущего. приветствуются примеры кода с описанией своей позиции. как известно добрая половина существующих языков синтаксически похожа на си. некоторые даже специально разрабатывались для похожести с целью более простого перехода. довольно неплохо скомпилировать светлые альтернативные идеи удалось создателям питона - чего только стоят синтаксически значимые отступы препятствующие написанию лапши. но и он не идеален - не смотря на большое количество сахара есть и немало костылей... сформируем критерии оценки того или иного подхода: * читаемость. программа должна легко восприниматься даже неподготовленным пользователем. не должно бы сложной витиеватой логики. программа должна визуально легко разбиваться на составляющие блоки. * надёжность. в языке не должно быть сложных конструкций делающих простые вещи. наоборот, для любого сложного алгоритма должны существовать достаточно простые конструкции. синтаксис должен быть такой, чтобы случайные опечатки не прошли незамеченными если не через компилятор, то хотябы через беглый просмотр кода программистом. * функциональность. должны быть возможность реализовать всё, что нужно, но без ущерба для первых двух пунктов. * скорость. как показывать опыт java, python, .net и других возможность компиляции в байткод простой виртуальной машины в современных условиях достаточно. тем не менее jit является солидным плюсом, но не в ущерб остальным пунктам.
рассмотрим аспект больших операторных блоков... посмотрите, например, на этот код на си-подобном языке. если убрать комменты в конце, то последний десяток строк вырождается в нагромождение фигурных скобочек. поэтому в конце операторных скобок трудолюбивые программисты вставляют комменты, позволяющие идентифицировать к какому из блоков они относятся. одних только отступов для уверенного восприятия человеком - мало. в идеале, ещё и иде должна цветом подсвечивать различные блоки, но на это не стоит уповать при разработке синтаксиса. в пхп частично решили эту проблему введя конструкции: foreach:endforeach; if:else:endif; примеры их использования можно найти тут но если надо подряд вложить несколько конструкций одного и того же типа, результат получается не лучше нагромождения фигурных скобочек. хорошим выходом из ситуации является, например, указание в конце циклического блока итерируемой переменной указанной в начале. например: for( var i in node_list ): // много кода endfor i; такие циклы можно свободно вкладывать друг в друга и при этом, дойдя до конца одного из них, сразу же понять какой из них был завершён, без необходимости считать отступы или сворачивать блоки в иде. многострочные операторные блоки встречаются во многих местах: * различные циклы * различные ветвления * определение структур данных (в том числе и передача параметров в функцию ) * определение собственно функций описанная проблема нашла элегантное решение в xml, но его синтаксис слабо подходит языку програмимрования. я предлагаю такие конструкции: присваивание переменной большого списка: PHP: +replaces 'a': 1 'b': 2 'c': 3 'd': 4 'e': 5 'f': 6 -replaces естественно ключи и значения на практике будут куда длиннее и возможно даже содержать вложенные блоки: PHP: +replaces 'a': 1 'b': 2 'c' 'd': 3 'g': 4 'e': 5 'f': 6 -replaces да, тут также как и в питоне отступы вначале строки семантически значимы, поэтому значение с ключом 'c' будет содержать вложеную хеш-таблицу (или "словарь" в терминологии питона).
Горбунов Олег, ага, я даже думаю лучше если строки будут бинарно-безопасными и способными содержать любые символы, как в sqlite. должна быть родная поддержка юникода как в яваскрипте, но тем не менее должна быть возможность и побайтового доступа.
теперь рассмотрим проблему контекста выполнения. тут я уже мельком рассмотривал эту проблему. если вкратце, то нехорошо, когда переменные из родительского и глобального контекста по умолчанию доступны и внутри функции. мы видим это в си-подобных языках. тем не менее, в пхп есть некоторые подвижки в этом плане: когда мы определяем функцию, для неё создаётся пустой контекст, так что даже если мы и забыли проинициализировать переменную, то это вовсе не значит, что мы будем работать с глобальной переменной. тем не менее запрет доступа к родительскому контексту несёт одни неудобства. в пхп для обхода этого нюанса ввели костыль под названием global - эта директива импортирует переменную из глобального контекста в локальный. но у такого решения есть два существенных не достатка: 1. мы не можем использовать удобное нам в локальном контексте имя. точнее можем, но старое имя также засоряет локальное пространство имён. 2. мы не имеем доступа к родительскому контексту, а он всё же куда полезней глобального. в связи с вышеописанных я предлагаю следующий синтаксис: PHP: #объявление локальной переменной: var1: 1 +var2 # многострочное выражение -var2 #импорт значений из родительского контекста: mx: import.mouse_x где import - это объект родительского контекста, который можно и проитерировать в случае необходимости...
Вот за что я никогда не любил паскале-подобные языки (а в особенности язык 1С), там это за все эти длинные (а в случае 1С всегда обязательные) begin, end.... Код (Text): Для а = 1 По 4 Цикл Если а = 1 Тогда б = 12; КонецЕсли; КонецЦикла; Никаким синтаксисом не заставить человека с бардаком в голове писать нормальный код ;-) Большая вложенность скобочек обусловлена, как правило, двумя вещами: 1. Неверный подход. 2. Плохой корпоративный (или собственный) стандарт на оформление кода. Кстати, я не люблю писать скобки, если оператор в условии или цикле один. Лично мне это облегчает жизнь. Когда совсем плохо надо просто вынести часть кода в отдельную функцию ;-) Это я все к тому, что синтаксис в языке дело десятое (какой формы скобочки, сколько запятых, надо ли ставить ";" в конце выражения и т.п.), важна функциональность этого синтаксиса, а не его красивость.
Дельфи Ну в принципе, мне легко осваивать ПХП (теперь иногда в дельфи даже лень приведение типов делать,), т.ч. для прикладных - дельфи, для веба - ПХП. Это со стороны простоты усваяемости и понимания%) Ну, любой компилируемый язык с отличной средой - дельфи, с(++/#). За отсутствие ексепшнов и try..except ПХП сильно теряет Тот, который подходит для задачи и в котором сам лучше ориентируешься. На ПХП не станешь делать обработку изображений, а на дельфи редко кто пишет cgi для всего сайта. вот тут стоит указать, что достаточны для круга задачь, где не требуется скорость. Ибо НЕТ, с его вездесущим ООП (блин, вызов randomize - класс, сдуреть можно, а в цикле получается кошмар) не для скорости.. но вообще, после конструкций типа: Код (Text): mov ecx, esi db $0f, $6e, $09 db $0f, $60, $ca db $0f, $6e, $59, $04 db $0f, $60, $da db $0f, $dd, $cb даже визуалбейсику радуешься (недолго, правда%)). Хотя по мне - асм довольно интересен. Чем то напоминает игру "Ханойские башни" - регистров мало, в стеке куча, перекладываешь туда-сюда Зато скорость - уухх %)
внутри функции у нас должен быть доступ к 4 пространствам имён: * локальный контекст. по дэфолту, когда мы пишем имя переменной она берётся из локального контекста. * переданные функции параметры. в общем случае переданные параметры - ассоциативный массив произвольной длинны. * родительский контекст * контекст объекта выполнения функции воспользуемся для записи имён контекстов служебным символом "бакс": $local - локальный контекст (все локальные переменные доступны как свойства этого объекта) $out - родительский контекст $input - переданные параметры $ - контекст объекта выполнения
я бы даже сказал - адреса на память, переданая через регистры (а если их много - через стек) %) все это жутко попахивает ПХП/Пером, речь о языках программирования или о языках в целом? А то мож я тут влез с эти асмом... %)
что не удивительно. во многострочных блоках begin не несёт никакого смысла, а для однострочных - слишком длинная запись. end же, не указывать какой блок завершился, чтобы это узнать - извольте рулить на начало блока. проблема не в том, чтобы не писать плохой код (синтаксисом это фиг исправишь), а в том, чтобы потом в нём было легко разобраться и чётко понять "гений автор или дурак" именно поэтому отступы должны быть семантически значимы. ок, как бы ты соптимизировал код, приведённый по первой ссылке во втором моём посте? это костыль. в "традиционных языках" много подобных костылей. и хотелось бы от них избавиться. нет, важна наглядность кода. чем синтаксис наглядней, тем легче в нём разобраться, тем сложнее допустить ошибку, тем легче найти и исправить уже допущенную. так называемая "функциональность языка" - это наличие простых конструкций, которые позволяют делать сложные вещи. хороший пример - регулярки. в простейшем случае они довольно наглядны и компактны, но в более-менее сложной регулярке уже сам чёрт ногу сломит. это функциональность ценой нагладности. не надо такого.
antonn, да, тут вообще речь идёт о языках высокого уровня. которым, вообще говоря, противопоказано оперировать со стэками, регистрами и прочим напрямую.
давай не будем выбирать тут лучший язык. надеюсь ты не считаешь дельфи идеалом? если да, то приведи пример кода на дельфи и аналогичный на си и объясни, чем дельфи лучше. если нет - хотелось бы поподробнее услышать о недостатках.
как показывает практика, наибольшего ускорения можно добиться совершенствованием алгоритма, на втором месте идёт переписывание узких мест под конкретную архитектуру (sse, mmx, shaders итп). излишнее же ковыряние с регистрами приводит лишь к увеличению количества багов, а падение программы гораздо хуже её быстрой но недолговременной работы. а всякие сферические измерения скорости в виде прогона рандомайза в цикле из миллиона итераций, пусть так и остаются в вакууме.
большое заблуждение. Язык высокого уровня позволящий абстрагироваться от асма, но имеющий инструментарий для тонкой доводки - вот это идеал. Кому надо - делают "как правильно и наглядно", надеясь на оптимизатор компилятора (или интепритатора), а кому то нужно тонко настроить все процессы. уже бегу и прыгаю %) мне как то поднадоело холиварить без результата (дада, ну покричим мы - и чего? ), поэтому выработан иммунитет нет, дельфи не считаю, считаю другой, но на нем нет ООП, а следовательно меня точно тут запинают да и для неподготовленного он никак не пойдет. Кстати, о неподготовленных - догадываетесь, почему паскаль и дельфи часто преподают в начальных курсах программирования? потому что он именно прост. Все эти "бегин..енд - это так длинно" - не больше чем придирки. Длинно? пишите на С, там скобочки Не код, а один большой коментарий Практически любую задачу можно решить на нескольких языках, и без разницы, как он там удобен и сколько там нужно строк для задания цикла. Хотя.. ветка холиварная, чет я забылся %)
antonn, нет, язык высокого уровня не должен ничего знать о низком уровне. именно из соображений портируемости. однако, я согласен, что он должен предоставлять возможность давать рекомендации интерпретатору на языке низкого уровня или через низкоуровневые модули.
так вот я потому и спросил, шла ли речь об интепритируемых языках (ведь именно они дают портабельность, ограниченую только св-вами системы, но не меняя синтаксис) или об языках в общем. Создать компилируемый язык для портабла - очень сложно, тот же КОЛ и МСК (в принципе - это дельфи, одна - просто очень компанктно компилирует, вторая для линукса) - можно писать с одним синтаксисом и под винду, и под линух, только вот код будет немеряно загажен директивами компилятору, как правильно обработать код под нужную ОС. Да и результат работает только на одной ОС. Интепретируемые позволяют создавать ядро вообще отдельно от собсно "языка", их код очень классно заставить работать сразу и на разных ОС практически не прилагая усилий - в ПХП мне это жутко нравится. Но и синтаксис его более чем удобен. Пусть местами нужно сделать на пару движений больше, чтобы получить какой нибудь аналог из питона, все равно скорость в них не главное. Т.ч. среди межплатформенных - ПХП мой выбор. И не надо, в принципе, ниче в нем удалять и переделывать, ну нет некоторых удобств. Многие просто не представляют, какие геморройные процессы происходят при самом обычном array("one" => array("two" => 0, "1" =>1)) - в ПХП легчайшим образом создается многомерные массивы, различныйших типов, в Дельфи или С - это кабздец просто, нужно выделять память, следить за указателями, вовремя их обнулять и подчищать за собой, плюс приведение к типам и вероятность получить AV (ну или что там, за выход не в свою память). Из-за этих удобств я часто поднимаю апач с ПХП для парсинга каких нибудь текстовиков, потому что на С я бы помер их парсить %) так.. чет меня унесло. В обще, раз ветка холиварная, я скажу свое слово - для кроссплатформы лучший язык - PHP! и попробуйте опровергнуть %)
нет, взяли студию, сдк для мобилы и скомпилировали. не помню, правда, удалось ли вообще скомпилировать...
dark-demon, не удалось... руки же кривые зы. читал где-то на форумах вопрос про связку apache+php+mysql для кпк... прикольная наверное была бы штука... я бы ей не пользовался
antonn Это не свойство интерпретируемого языка. Просто ПХП предназначен для достаточно универсальной задачи - отдать текстовый файл. С окнами ему не работать, и служб ему не запускать. Поэтому и универсальность. А то, интерпретируемый он или компилируемый - это дело десятое. Джаву вот можно при желании назвать компилируемым языком (я про JIT, а не про байт-код). Однако поди ж ты - работает на разных платформах без директив компилятору.
dark-demon Труъ язык программирования - это когда ты пишешь задание на русском, а компилятор выдает тебе готовую программу в машинном коде без багов. Но над таким лучше не думать, иначе все останемся без работы. Все остальное - лишь приближения, и вряд ли что-то кардинально новое здесь удастся изобрести.