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

DM>А можете нарисовать сортировку массива? Очень интересно, как будет выглядеть.

пример на Lucid из википедии

qsort(a) = if eof(first a) then a else follow(qsort(b0),qsort(b1)) fi
  where
     p = first a < a;
     b0 = a whenever p;
     b1 = a whenever not p;
     follow(x,y) = if xdone then y upon xdone else x fi
                     where
                        xdone = iseod x fby xdone or iseod x; 
                     end
  end

    --------> whenever -----> qsort ---------
   |             ^                           |
   |             |                           |
   |            not                          |
   |             ^                           |
   |---> first   |                           |
   |       |     |                           |
   |       V     |                           |
   |---> less ---                            |
   |             |                           |
   |             V                           V
---+--------> whenever -----> qsort -----> conc -------> ifthenelse ----->
   |                                                       ^   ^
   |                                                       |   |
    --------> next ----> first ------> iseod --------------    |
   |                                                           |
    -----------------------------------------------------------

Если кто хочет побаловаться — есть lucid-synchrone, который работает поверх Ocaml

Alex EXO wrote:

> Да и математические формулы — скорее текст с расширенным символьным
> рядом, чем картинки.
А интересно, удалось ли кому стырить в программирование из математики красивые формулы? Которые, конечно, не картинки, но таки не одномерный текст, а довольно нелинейные объекты, там всякие верхние/нижние индексы, структура операторов (что интеграл может иметь область интегрирования, а может иметь только функцию, плюс по каким переменным), формализовать "дефолтные значения".
Скажем,

выглядит довольно неплохо, даже по сравнению с аналогами на других супер-пупер функциональных языках.

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

.>выглядит довольно неплохо, даже по сравнению с аналогами на других супер-пупер функциональных языках.
APL — http://en.wikipedia.org/wiki/APL_(programming_language)#Examples

Здравствуйте, ., Вы писали:
.>А интересно, удалось ли кому стырить в программирование из математики красивые формулы? Которые, конечно, не картинки, но таки не одномерный текст, а довольно нелинейные объекты, там всякие верхние/нижние индексы, структура операторов (что интеграл может иметь область интегрирования, а может иметь только функцию, плюс по каким переменным), формализовать "дефолтные значения".
.>Скажем,
.>
.>выглядит довольно неплохо, даже по сравнению с аналогами на других супер-пупер функциональных языках.

Новый язык Sun — Fortress.
Вот фрагмент кода в pdf: http://research.sun.com/projects/plrg/faq/NAS-CG.pdf
Парсят они эту жуть, кстати, модным PEG парсером XTC Rats!.

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

.>Скажем,
.>
.>выглядит довольно неплохо, даже по сравнению с аналогами на других супер-пупер функциональных языках.

Только вот мне кажется, что array — эт не из математики (там скорей было бы какая-нибудь A)

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

.>А интересно, удалось ли кому стырить в программирование из математики красивые формулы?

В Маткаде очень давно есть похожая смесь математики и программирования. Вот, например, умножение матриц:


Это просто пример, я знаю, что есть уже готовая операция умножения, и что можно было сделать проще.

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

DM>>А можете нарисовать сортировку массива? Очень интересно, как будет выглядеть.

Z>пример на Lucid

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

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

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

DM>>>А можете нарисовать сортировку массива? Очень интересно, как будет выглядеть.

Z>>пример на Lucid

DM>Но в данном инструменте первичен текст, диаграмма не содержит всей необходимой информации, т.е. сама самостоятельным языком не является, как я понял.

Является, просто для бесплатных версий языков нет соответствующих IDE. Lucid это практически Lustre, а Lustre — это SCADE:

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

.>А интересно, удалось ли кому стырить в программирование из математики красивые формулы? Которые, конечно, не картинки, но таки не одномерный текст,

Насчет неодномерности записи:
http://en.wikipedia.org/wiki/Epigram_(programming_language)

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

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

.>>А интересно, удалось ли кому стырить в программирование из математики красивые формулы? Которые, конечно, не картинки, но таки не одномерный текст,

D>Насчет неодномерности записи:
D>http://en.wikipedia.org/wiki/Epigram_(programming_language)

Интересно чем же запись эпиграмовская стала вдруг сильно неодномерна? Разделение части конструкции на верхнюю/нижнюю сути, на мой взгляд, не меняет.
Визуально оно, наверное, поудобней, но вот в реальности принципиально от записи аля в строчку <Верхнее>, <Нижнее> не отличается.
А то так и языки учитывающие отступы надо будет неодномерными считать (хотя даже само понятие очень спорно и не понятно имеет ли большой смысл)
P.S. Ссылки лучше корректные давать (проверять)

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

К>P.S. Ссылки лучше корректные давать (проверять)
это не я это форум решил, что правая скобочка уже не ссылка.

Википедия про эпиграмм. Попытка II-ая.

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

А зачем нужна "многомерная запись"? Что она даст? Повысит удельную плотность информации на квадратный пиксель? Думаю неплохо получится проанализировать результат подобного повышения плотности просто уменьшив размер шрифта. Мне понятнее не становиться, мыслительный процесс не улучшается.

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

Не касательно этого языка, а вообще всех подобных:
На мой взгляд использовать их вместо текста — это извращение.

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

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

J>Прикольный язык. Думаю, за такими системами будущее!
За такими системами прошлое . Понаписали таких систем уже до черта, и переодически снова появляются желающие писать. Тема столь же вечная, как и язык программирования на основе русского языка, как специализированные языки, понятные бухгалтеру. Типа — а давайте ка мы избавимся от программистов и пусть его работу выполняет специалист в предметной области, который программировать не умеет. Вот только не учитывается одно — тот, для кого выучить какой-то язык программирования представляет сложность — тот обычно к программированию не способен вообще, и никакая мегасистема на основе построения программы из кубиков ему не поможет. И в результате в конечном счете придется кликать мышкой на этом языке для начинающих, который имеет кучу ограничений, короче придется со всем этим возиться людям, которые программировать более-менее умеют, а не тем, для кого язык предназначался изначально. Профессионалов такой язык отпугнет, так как по возможностям язык будет отставать от современных лет так на 20, а дилетанты на нем такого напишут, что будет один сплошной баг .
А почему за такими системами прошлое, я, например, щас занимаюсь тем, что переписываю с нуля один достаточно приличный проект, который изначально разрабатывался на фреймворке, где все рисовалось мышкой. Ну и довелось в свое время мне и мышкой порисовать достаточно сложные системы. У таких систем есть несколько очень сильных недостатков, от которых не избавиться принципиально:
1) Невозможность сделать diff и merge, и чтоб можно было понять что изменилось. При работе в команде файл приходится лочить, чтоб никто его не менял. Забудешь залочить — с другими членами команды синхронизоваться не получится, придется все писать заново. В принципе, теоретически наверно это можно сделать, но сейчас такого нет, и появится это ох как не скоро;
2) Мышкой набирать получится один черт на порядок медленнее, чем при набивании текста в нормальной IDE. Да, проблема медленного набора решаема, например путем заучивания сотни хоткеев. Но в этом случае для обучения работы с этой системой потребуется до черта времени. И кстати, полностью мышкой один черт не получится — переменным, методам, классам — всему этому надо давать имена.
3) До черта времени требуется, чтобы нормально расставить элементы. Стрелочки чтоб там не пересекались, не налазили сами компоненты друг на друга. Автоформат сделать настолько интеллектуальный, чтоб он мог форматировать сложную схемку для чтения человеком, обеспечить возможность частичного форматирования — крайне тяжелая задача. Теоретически может быть когда-нибудь напишут такой автоформаттер, но пока — увы и ах, автоформаттеры даже для текстовых файлов работают не идеально;
4) Рефакторинг. Тоже для таких систем сделать крайне проблематично. На текущем этапе проще переписать все заново, чем сделать простейший и безопаснейший extract method, про более сложные виды рефакторинга вообще можно забыть — проще переписать все заново;
5) Логика одинаковой сложности будет занимать в текстовом виде гораздо меньшую площадь экрана, чем в графическом. На картинках зачастую показывается только часть необходимой информации, в этом случае что-то разобрать еще можно. Теоретически это даже плюс, так как будет вынуждать писать более просто. Но практически, никто рефакторингом заморачиваться не будет, и будут до крайней степени усложнять диаграмки;

В принципе, теоретически когда-нибудь возможно и удастся кому-то придумать достаточно удобный графический интерфейс, который будет так же удобен, как современные текстовые IDE. Вот только будут ли этим пользоваться, так как к тому времени текстовые среды разработки станут еще более удобными ? И кстати, такая мегасистема будет жрать ресурсов на порядок больше чем текстовая — для приличной работы потребуется наверно терабайт оперативки и 100 террагерцовых процессоров .

Здравствуйте, Огнеплюх, Вы писали:

О>Т.к. если провести паралель с электронникой то это уже похоже на создание схем. На счет того что пишут — плохо читается не согласен. Любая схема читается гораздо лучше чем текст. Есть понятие мастшабирования и выделения — то что не нужно на данный момент можно скрыть/уменьшить. Преставте что электрическую схему бы описывали : эммитер транзистора A подключается к эммитору транзистора Б и т.д.
Как я понял, это мнение PMа, а не разработчика?

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

E> все рисовалось мышкой

В Scratch (и E-Toys) код не рисуется мышкой. Это скорее что-то вроде автокомплита. Т.е. из списка доступных выбирается объект, из списка доступных над объектом действий выбирается действие. Естественно професионалу удобнее писать в редакторе с подсказками от среды. Но не специалисту может быть проще с такой вот штукой. Она, можно сказать, фиксирует синтаксис. Минус — нельзя делать сложные конструкции, плюс — трудно ошибиться. Хотя, для особо одарённых можно переключится в режим, когда скрипт вводится в простом редакторе кода. В майнстриме гораздо более примитивный вариант такого — это макросы в MS Access.

Есть в Squeak еще один режим "графического" представления кода. Tiles (пример смысла никакого не имеет):


Есть однозначное соответсвие между кодом и таким отображением. В таком режиме можно даже код вводить, но у меня не получилось

Здравствуйте, Andrei N.Sobchuck, Вы писали:

[cut]
ANS>Есть в Squeak еще один режим "графического" представления кода. Tiles (пример смысла никакого не имеет):
[cut]
ANS>Есть однозначное соответсвие между кодом и таким отображением. В таком режиме можно даже код вводить, но у меня не получилось
Помнится для людей испытывающих проблемы со скобочками был какой-то плагин к емаксу, который разными цветами помечал блоки.

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

К>Помнится для людей испытывающих проблемы со скобочками был какой-то плагин к емаксу, который разными цветами помечал блоки.

Ага. Вероятно это из той же оперы. Но тут "красота" наводится локально в пределах одного метода. Можно ли отобразить граф без потери выразительности — не ясно.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, Курилка, Вы писали:

К>>Помнится для людей испытывающих проблемы со скобочками был какой-то плагин к емаксу, который разными цветами помечал блоки.

ANS>Ага. Вероятно это из той же оперы. Но тут "красота" наводится локально в пределах одного метода. Можно ли отобразить граф без потери выразительности — не ясно.

Ну если совсем уж общий граф строить, то далеко не факт что на плоскости без пересечений его можно будет нарисовать, забавно было бы посмотреть на 3-мерные программы

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

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

J>>Прикольный язык. Думаю, за такими системами будущее!
E>За такими системами прошлое .
Возможно. Но я знаю несколько успешных примеров даже в совсем программистских местах.
Это всяческие визуальные редакторы xslt, для него есть и diff и merge, xml всё таки, рефакторинг; мышкой его набирать часто быстре, особенно в случае когда надо просто сбиндить один xml в другой(см продукты altova). wsdl и xsd, не непосредственное программирование, но близко. bpel — вообще бейсик на xml-e(см netbeans, oracle jdeveloper). Теоретически bpel создавался как инструмент скорее продвинутого менеджера, чем программиста, о чем свидетельствуют совершенно нечитаемые без визуального редактора простыни xml даже для простых случаев. Еще есть ESB решения конфиг к которым тоже на xml у которых визуальные редакторы либо уже есть, либо находятся в процессе написания, потому что без них туго.

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

D>А зачем нужна "многомерная запись"? Что она даст? Повысит удельную плотность информации на квадратный пиксель? Думаю неплохо получится проанализировать результат подобного повышения плотности просто уменьшив размер шрифта. Мне понятнее не становиться, мыслительный процесс не улучшается.

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

И не зря же придумали такую запись в математике. И не спроста она пользуется популярностью.
Большинству людей прочитать формулу, записанную в строку, всё-таки сложнее, чем прочитать её в структурном виде.

Но, я думаю, записывать/редактировать формулы в структурном виде на компьютере мало кому покажется удобным.

Поэтому оптимальным (с моей точки зрения) вариантом будет двойное представление информации. В одномерно-текстовом виде для редактирования и в структурном виде для чтения.