А как же "Alternative Web Language"??

Немного посмотрел на язык, даже запускал программы. Сразу скажу - немного испугал синтаксис - страшненький, по-моему, хотя кому-как 
Но, автору респект за упорство и проделанную работу, имеющую результатом вполне работоспособный язык.

Мне вообще новые языки интересны чисто с практической точки зрения, по этому я смотрю на них прежде всего в таких разрезах:

1) На что нацелен язык, т.е. в какой области применения позиционируется
2) Синтаксис языка, т.е. желательна его понятность, простота и синтаксическая чистота (особенно если это язык общего назначения) - это прямым образом отобразится на его распространенности, поскольку "встречают по одежке".
3) Чем он отличается от нынесуществующих, и какова в нем изюминка, чем он лучше их и соответственно какой смысл выбрать именно его, а не что нибуть-другое, ведь очевидно, что выбирать новую еще не окрепшую технологию - это всегда большой риск.

Можно ли прокомментировать по этим пунктам?

Это сообщение отредактировал(а) cherep - 1.12.2006, 17:13

Именно так. Просто, пока я прикидываю перспективы AWL как исключительно клиентской Web-технологии (если так понятнее – как альтернативу JavaScript/Flash/SVG/XHTML, а не ASP/PHP/SSI и т.д.). Конечно, если бы еще AWL имелся на сервере, причем серверные компоненты гладко и без швов интегрировались с клиентскими – это было б просто замечательно. Но пока я об этом даже не думаю: т.к. прежде, чем всерьез планировать это, надо иметь более четкое представление о собственной функциональности AWL клиента.



Во-первых, на самом деле синтаксис не такой уж страшный ;) Впрочем, если есть конкретные идеи, что можно улучшить – предлагайте, я слушаю.
Во-вторых, что более важно, синтаксис очень вариантный. В AWL действительно уйма операций -- но практически все допускают функциональную запись как альтернативу "операторной" (семантически, никакой разницы нет). Т.е. не нравятся условные операции в виде a ? b : c -- пишите if (a, b, c); не нравятся циклы в виде a ?? b -- пишите while (a, b) или даже while (a) :: b ну и так далее.
(В опубликованных примерах, действительно, в основном используется «операторный» синтаксис, т.к. он мне нравится своей компактностью. Но я свои вкусы никому не навязываю.)



Спасибо.

Во-первых, как Alternative Web Language (клиентскую web-технологию). В принципе, в AWL реализуемо будет все то, для чего сейчас используются HTML/CSS (форматирование гипертекста, стилевая разметка и т.п.), Javascript (интерактивные компоненты и взаимодействие с пользователем) и ActionScript/SVG (векторная графика и анимация). Скоро будет на сайте небольшой проект того, как это могло бы выглядеть в реальной жизни.

Во-вторых, просто в качестве вполне самостоятельного переносимого скрипт языка.

В-третьих, возможно, как встраиваемый скрипт-язык для больших систем (наподобие Lua).



Согласен, добавлю от себя, что любой синтаксис – это некий компромисс между практичностью (которая требует, например, использовать арифметические операции с привычной системой приоритетов), и, как вы говорите, «синтаксической чистотой» (самый «чистый» синтаксис из возможных в LISP – вся программа состоит из атомов и списков – только практичен ли он?) AWL как раз хорош тем, что позволяет во многих ситуациях выбрать синтаксис по вкусу.



Сравнивать со всеми существующими языками будет очень долго. ;)
Для примера, можно взять Perl, Python и Ruby. (Сразу скажу, что из этой тройки я хорошо знаком только с Perl, насчет остальных языков могу и ошибаться.)

Синтаксис: если вам не нравится AWL, то что вы скажете о Perl ;) ?
Нет, про сам язык ничего плохого сказать не могу, но все-таки синтаксис… Особенно явные анахронизмы, оставшиеся от юниксовских оболочек и AWK: переменные с сигилами, barewords, интерполяция в строках, замечательные имена системных переменных типа $% или $:. (Многое из Perl-синтаксиса унаследовано в Ruby, что последний не красит.)
Вот в Python синтаксис проще и логичней – но то, что слишком большую роль в нем играют отступы и концы строк, мне кажется изрядным недостатком.

Вообще, то что в AWL нет ключевых слов, как таковых, я считаю большой удачей. Есть только стандартные функторы. Собственно синтаксис языка менять нельзя, но определять новые функторы (фактически, переименовывать старые) можно сколько угодно. Кстати, AWL полностью интернационален: хотя имена стандартных функторов имеют англоязычную основу -- определите, скажем, русскоязычные синонимы для них, и получится русский AWL.

В отличие от AWL, Perl вообще неспособен работать интерактивно (Python может, насчет Ruby не знаю).

Далее, в AWL последовательно реализован «принцип эквивалентности кода и данных». Могу ошибаться, но, по-моему, ни в одном из рассматриваемых выше языков этого нет. Соответственно, невозможны напрямую такие вещи, как «ленивое» присваивание или передача параметров.

Реализация ООП в Perl и Python мне кажется не слишком удачной. Особенно в Perl, где объекты, фактически, являются просто хэшами, которым придан «объектный» вид. Вот в Ruby с ООП хорошо (даже слишком: «чисто объектный» подход, где все функции является методами, мне не нравится).

В отличие от AWL, ни в одном из рассматриваемых языков нет многомерных массивов. (Можно, конечно, создать массив ссылок на массивы и т.п. --  но полноценным многомерным массивам это не замена, затрудняет реализацию таких операций, как реструктурирование, транспонирование, итерация по любому измерению и т.п. -- в AWL всего этого пока нет, но планируется).

Реализация ассоциативных массивов в AWL существенно лучше, чем в Perl, т.к. допускает произвольный тип ключей.

Наконец, учтите встроенные графические возможности. Конечно, к любому из перечисленных языков можно прикрутить внешнюю графическую библиотеку, вроде Tk, wxWidgets или Qt. Но в результате получается нечто достаточно монстрообразное, и не очень пригодное для использования на компьютерах малой мощности. Ну а AWL с полноценной графической подсистемой вполне уместится даже в слабеньком сотовом телефоне -- во всяком случае, надеюсь на это.

Собственно, пока все. Если есть еще вопросы -- задавайте.


Это сообщение отредактировал(а) regis - 4.12.2006, 11:49

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

В Python-е numarray:

и Numpy:


Все за счет расширяемости языка. Расширяемость бы и AWL очень пригодилась -- не мешает об этом все-таки подумать.


как и в Питоне -- dict.


Для питона, опять же, монстрообразность проявляется только при сборке в Windows независимого от интерпретатора и библиотек приложения. Для *nix библиотеки родные. Плюс такого подхода -- кроссплатформенность.

Хорошие расширения, только хочу заметить, что поддерживаются исключительно числовые массивы. В AWL тип элементов может быть любым.



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



В Питоне есть, я знаю.



Говоря о монстрообразности, я имел в виду не собственно размер исполняемого файла: понятно, что при использовании внешних библиотек он будет намного меньше -- но сам-то код из них никуда не денется. Так что, ни память, ни процессорные ресурсы не уменьшатся от того, что библиотеки разделяемые.

Добавлено @ 13:33 
Кстати, раз уж мы говорим о графических возможностях...

Раз "низкоуровневая" оконная графика для AWL уже есть, пора подумать о реализации более высокоуровневым вещей, в первую очередь простых элементов управления: кнопки разных типов, поля ввода, списки и т.п. Тут, как я понимаю, возможны два подхода.

Первый (Java + AWT, JavaScript и Web): использовать "родные" для оконной среды элементы управления.

Второй (Java+Swing, Perl + Prima, TCL + Tk): реализовывать самому, вручную рисовать и обрабатывать события клавиатуры и мыши.

Первый подход, очевидно, проще, (и скорее всего, эффективнее) но системно-зависим. Второй подход потребует куда больше труда. Зато: полная переносимость, все элементы управления выглядят одинаково под любой платформой, проигрыш в производительности, хоть и есть, но незначительный (когда я увидел Prima-приложения под Perl, было трудно поверить, что все элементы управления отрисовываются Perl-кодом).

Хотел бы знать ваше мнение, какой подход лучше, и вообще что стоит брать за концептуальную основу. Взаимодействие виджетов, например, очень изящно в Qt реализовано (сигналы + слоты), хотелось бы в AWL иметь нечто подобное... В общем, буду рад идеям.



Это сообщение отредактировал(а) regis - 8.12.2006, 13:23

На сайте есть серьезные обновления.

- Выложена новая версия мануала в HTML/PDF. Наконец-то более-менее внятно документированы классы, объекты, виртуальные функции (эти главы еще будут дорабатываться).

- И еще один новый документ -- AWL-graphics.html -- более-менее внятно описывает то, как в среде AWL работает графика. Это особенно советую почитать. Как мне кажется, графической системы, построенной на подобной идеологии, ни в одном из распространенных языков нет. (Даже странно -- преимущества, на мой взгляд, вполне очевидны...)

Ну вот пока и все. Лично мне кажется, что за прошедший год удалось кое-чего реального добиться. ;) Надеюсь, что в следующем удастся добиться намного больше!

С наступающим всех!

Кстати, на сайте, наконец-то, выложена моя многострадальная статья "Ошибка тысячелетия". Те, кто ее не читал в свое время, теперь имеют возможность прочесть.

Сегодня выложил новую версию интерпретатора (0.5.1)!

http://awl-project.narod.ru/awl-000501.zip

И в разделе "Примеры" на сайте (http://awl-project.narod.ru/awl-examp.htm) тоже имеется кое-что новенькое...


Это сообщение отредактировал(а) regis - 1.2.2007, 17:10

Есть идея добавить материал про AWL, в англоязычную/русскоязычную Wikipedia. Кто-нибудь здесь имеет опыт активной работы над Википедией?

Жми http://ru.wikipedia.org/wiki/AWL , там жми "Создать новую страницу", пиши. Вёрстка элементарна, , всё что между == == это заголовок (количество = определяют уровень), блок текста отделённый пробелами (indent) это код. Там же ссылка на песочницу, где можно опробовать вёрстку. Пусть по началу не красиво, как только появиться, найдётся куча народу что поправят (я поправлю).

Спасибо! Но кое-что я уже сотворил самостоятельно:

http://en.wikipedia.org/wiki/AWL_programming_language

Не судите строго -- это пока только first attempt. На следующей неделе планирую добавить еще раздел-другой, прежде всего про графику и верстку документов.
Комментарии, идеи и исправления моего English (который, боюсь, far from perfect) приветствуются...

Новая версия AWL -- 0.5.3.

Самое существенное, что в ней реализовано: базисные средства работы с метадокументами, реализующими форматирование и вывод текста.
Несколько примеров того, как это работает, я тоже выложил; см. в самом конце http://awl-project.narod.ru/awl_examp_RU.htm



Это сообщение отредактировал(а) regis - 23.4.2007, 13:55

Немного не точно. С типами есть два свойства:

• динамичные (duck typing) и статичные
• строгая и не строгая типизация

Первое определяет является ли указание типа обязательным (статичные) или отслеживается транслятором (динамичные). Второе допускает не явное преобразование типов (не строгая, т.е. строки в числа и т.п) или нет (строгая, явное конвертирование необходимо). В таком свете AWL будет языком с динамичными типами и не строгой типизацией если быть точным 

Отсутствие запятых в списке аргументов функции сбивает с толку, особенно осознавая что при вызове запятые таки ставим. ИМХО это ухудшает читабельность.


Такая запись просто угнетает. Здесь же не конкатенация, а собирается список, который затем пугающего вида "<:" печатается в консоль? ИМХО как то это не эффективно со списком выглядит. Лучше сделать явный оператор конкатенации строк (уже не помню был такой у тебя или нет...), отличный от арифметического сложения.

Вижу активное использование рекурсии, но на сколько эффективно выполнены вызовы? Заменяет ли компиллер простые вызовы inline вставками кода? tail-recursion оптимизации? Иначе будет тормозить...


Что имелось в виду? То что свойство при каждом обращении ищется вновь и вновь в run-time'е? Так это просто (если объект хештаблицей реализовать,  большинство скриптовых движков такие) и не эффективно по сравнению высчитыванием смещения на момент трансляции.

Чего я ещё не вижу это хорошего синтаксиса, уж больно он страшен в нынешнем виде. Также хочется быть кратким, следовательно должно быть много syntatic sugar. К примеру (язык от балды):


В две строчки зачитали файл и просчитали хеши для каждого блока, затем отправили серверу на поиск совпадений. Если отбросить API, то видим очень выразительную [for in] конструкцию. Вот что то подобное хотелось бы в AWL.

Хммммммммм. А почему конкатенация эффективнее в данном случае?





Угу. +1

Чисто субъективное мнение, "выглядит" не эффективно в плане создания списка   Хотя строка после конкатенации тоже обычно связанный список (копировать символы в новую глупо и расточительно). Тут скорее вопрос в читабельности и в личных предубеждениях.