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

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

J>>>Язык программирования Microsoft Visual Programming Language (VPL)...
M>>Это вариант от MS лишь бы обшестандартный BPEL не реализовывать?

L>Будет бипел в следующем WF.

Дык, он вроде там уже давно есть
http://www.microsoft.com/downloads/details.aspx?FamilyID=6d0daf00-f689-4e61-88e6-cbe6f668e6a3&DisplayLang=en

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

L>>Будет бипел в следующем WF.

V>Дык, он вроде там уже давно есть
V>http://www.microsoft.com/downloads/details.aspx?FamilyID=6d0daf00-f689-4e61-88e6-cbe6f668e6a3&DisplayLang=en

Community Technology Preview

Z>>Подобный подход чаcто применяют в пакетах 3D графики: Virtools, XSI 7.0 ICE

P>Я бы сюда добавил операторы 3Д пакета Houdini. Говорят, что это очень удобный и быстрый в программировании/настройке подход.

Что-то похожее есть и в Apple Shake

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

M>>Как только человек хоть немного разберётся с языком — ему будет удобнее текстовое или псевдо-текстовое (с форматированием, с иконками) представление.

J>Вот кусок программы, с одного взгяда понятно как это работает, даже код читать не надо

Издеваешся, да? Какой то Merge, какие-то точки соединения у квадратиков...
На мой взгляд удобство весьма сомнительно чистой с той точки зрения, что чтобы написать эту программулину (которая на С займет строчки 3) девелоперу придется усиленно шуршать по какому-нить тулбару, выбирая нужный ему квадратик, линию, таская линии к точкам соединения и т.п. У меня щас программулина — так там 1.5 млн строк, и я даже представить боюсь, как бы она выглядела, будь она вот в таком виде напедалина. Да и чисто механически делаеть это неудобно, воспринимается тяжело, а изменяется еще тяжелее. Сколько нужно усилий, чтобы обрамить эту всю твою картинку циклом? В тексте — 2-3 строчки, в этих всех картиночках — куча напряга с какими-то мерджами непонятными и ни о чем не говорящими. А чтобы кусок кода вынести в отдельную функцию?
Короче на мой взгляд перспектив нет.

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

Возврат от письменности обратно к наскальной живописи?

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

J>Интересно, имеет такой язык будущее? Дело в том, что я тоже пытаюсь создать подобный скриптовый язык, для автоматизации в Windows

Как уже неоднократно было написано выше, множество подобных языков уже давно имеют настоящее. Мне довелось познакомиться поближе с подобной системой, существующей уже лет 15, — LabVIEW, — и её языком G (Г ). Да, при первом взгляде на пример небольшой диаграммы умиляешься, как всё красиво, "интуитивно" и разноцветно. Но когда нужно что-либо при помощи этого сделать... Оно подходит разве что для задания правил для dial-up звонилки При более-менее серьёзной логике начанается такое спагетти из проводов, что уже не понимаешь что с чем соединяется и куда этот dataflow собственно flow. Да, есть локальные переменные, позволяющие разрывать непрерывные связи. Привет, goto!
Сам принцип dataflow имеет как преимущества, так и недостатки. Например, когда требуется выполнить некоторые действия строго последовательно, приходится городить огород специальными средствами. И при работе с циклами и другими управляющими структурами на этой почве возникает множество нюансов.
Если бы мне дали выбор между диаграммой и текстом, я бы выбрал текст

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

Z>>>Подобный подход чаcто применяют в пакетах 3D графики: Virtools, XSI 7.0 ICE
P>>Я бы сюда добавил операторы 3Д пакета Houdini. Говорят, что это очень удобный и быстрый в программировании/настройке подход.
M>Что-то похожее есть и в Apple Shake

и в vvvv (http://vvvv.org)

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

J>Язык программирования Microsoft Visual Programming Language (VPL) — это средство разработки приложений, в котором используется модель

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

Помоему будущее за схемами в программировании , а именно соединением компонентов друг с другом. Некоторые компоненты будут объединяться в более функциональные. Также как это делают в любом радиотехническом приборе в том числе и вашем любимом компьютере.

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

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

J>Интересно, имеет такой язык будущее?

Конечно, имеет. При одном , правда, условии — что эта программа имеет такое же отношение к программированию, как постройка домика из кубиков первоклассником — к архитектуре. Но таких программ сейчас большинство, так что успех будет

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

О>И собирать программы в будущем сможет любой пользователь, также как сейчас может собрать компьютер. Зная что куда втыкать.
PCI-Express карту в AGP-слот не впихнёшь при всём желании. В то же время карту PCI вполне можно заменить на карточку PCI другого производителя. Почему? А потому что интерфейсы и протоколы проработаны и выдерживается производителем. А как с этим у строительных программных блоков будет?

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

Точно также. Если IInput <> IOutput то компонент "втыкаться" не будет.
Например в .NET или Delphi если замечали у компонента ListView , TreeView и т.д. есть такой "слот"/свойство называется ImageList из которого берутся иконки для отображения.
Так вот туда воткнуть можно только ImageList, другой компонент воткнуть не получиться.
Также как AGP устройство в PCI-E слот.

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

J>А мне графическое представление больше нравится, наверное из-за того, что я люблю рисованием заниматься.
J>Вот кусок программы, с одного взгяда понятно как это работает, даже код читать не надо

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

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

J>Язык программирования Microsoft Visual Programming Language (VPL) — это средство разработки приложений, в котором используется модель
а вот интересно. я таких штук много видел, но везде либо примитивный flow данных с переключателями(симулинк в матлабе), либо примитивный процедурный подход на уровне фортрана, ну еще дизайнеры sql запросов видел, но это уже скорее схема, чем ЯП. Как создавать софт такими примитивными средствами? Почему не видно реализаций более абстрактных и высокоуровневых категорий, чем процедуры и функций?

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

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

J>>Язык программирования Microsoft Visual Programming Language (VPL) — это средство разработки приложений, в котором используется модель
D>а вот интересно. я таких штук много видел, но везде либо примитивный flow данных с переключателями(симулинк в матлабе), либо примитивный процедурный подход на уровне фортрана, ну еще дизайнеры sql запросов видел, но это уже скорее схема, чем ЯП. Как создавать софт такими примитивными средствами? Почему не видно реализаций более абстрактных и высокоуровневых категорий, чем процедуры и функций?

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

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

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

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

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

Обычно она присутствует в виде отдельного кубика

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

M>>Scratch — интерпретатор «детского» языка программирования, придуманный в Media Lab

J>Прикольный язык. Думаю, за такими системами будущее!

Это будущее уже 30 лет наступить не может По сути Scratch это пост-EToys разработка. Для обучения детей E-Toys доказала свою эффективность.
Т.к. массовое распространение компьютеров только начинается, то, возможно, у таких систем и есть будущее где-то кроме обучения. Но, вряд ли

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


F>я так понял что это вот это где-то записано? Мамачки... Я даже не уверен что понял что-то в том рисунке, что за странный Merge?

Это потому, что автор диаграммы еще не дошел до структурного программирования, а остался на уровне GoTo. Интересно, как он перерисует диаграмму, когда поймёт, что for/while это не if+goto, а отдельная конструкция.

Здравствуйте, jangle, Вы писали:
J>Интересно, имеет такой язык будущее?

На мой взгляд — НЕТ.
За исключением может быть каких-нибудь отдельных частных применений.

Поскольку программирование, это не код, а способ думать. И этот способ ближе к письменной речи, нежели к картинкам.
И если посмотреть на аналогии, то текстовая запись оказалась перспективнее иероглифов.
Да и математические формулы — скорее текст с расширенным символьным рядом, чем картинки.

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

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

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

J>>Язык программирования Microsoft Visual Programming Language (VPL) — это средство разработки приложений, в котором используется модель
D>а вот интересно. я таких штук много видел, но везде либо примитивный flow данных с переключателями(симулинк в матлабе), либо примитивный процедурный подход на уровне фортрана, ну еще дизайнеры sql запросов видел, но это уже скорее схема, чем ЯП. Как создавать софт такими примитивными средствами? Почему не видно реализаций более абстрактных и высокоуровневых категорий, чем процедуры и функций?

Я, к сожалению, не имею возможности проверить на практике, что такое VPL от MS, но думаю это не плохая штука и хотел бы напомнить знатокам о том, что в родном отечестве некогда развивалось такое направление и не просто развивалось, а активно применялось с большим успехом (да и сейчас применяется).
Делалось это усилиями коллектика центра автоматики и приборостроения им. академика Н. Пилюгина и ИПМ им. Келдыша. В те годы шла активная разработка МКС "Буран" и по инициаливе Юрия Трунова совместно в ИПМ были созданы три языка ПРОЛ2, ДИПОЛЬ и ЛАКС (руководители проектов: Виктор Крюков, Владимир Луцикович и Константин Федоров соотв.). Каждый язык использовался для своих задач и с другими не пересекался: ПРОЛ2 — для разработки бортовых комплексных программ Бурана , ДИПОЛЬ — для создания наземных программ Бурана и ЛАКС — для моделирования. Языки и инструменты были созданы, но возникли сложности с организацикй взаимодействия специалистов-прикладников и программистов. Когда эта проблема была осознана, Трунов выступил с идеей создания нового инструмена, который бы в песпективе заменил три существующие. Такая задача была поставлена перед Владимиров Параджановым, руководителем комплексной группы центра автоматики и приборостроения им. академика Н. Пилюгина. Но Параджанов несколько пересмотрел условия задачи, т.к. понимал, что еще один новый язык проблемы не решит. Нужен был принципиально иной подход, который позволил бы совсем-не-программистам и совсем-уже-программистам разговаривать на одном языке, т.е. думать и решать задачи в схожих понятиях. По сути замахнулись на святое, на способ мышления, на то, что бы улучшить/изменить работу ума. И как ни странно это звучит, задача была решена. Был создан язык ДРАКОН, графический язык. Цель и задачи этого языка были:
1. Предложить эффективные средства для описания структуры человеческой деятельности.
2. Предоставить человеку такие языковые средства, которые резко упро щают восприятие сложных процедурных проблем и общение с кол легами, делают непонятное понятным и за счет этого буквально заставляют человека мыслить отчетливо, глубоко и продуктивно. В этих условиях вероятность заблуждений, просчетов и ошибок неизбежно падает, а производительность растет.
3. Радикально облегчить межотраслевое и междисциплинарное общение между представителями разных организаций, ведомств, отделов, лабораторий, научных школ и профессий.
4. Устранить или уменьшить барьеры взаимного непонимания между работниками различных специальностей (врачами и физиками, математиками и конструкторами, биологами и экономистами и т. д.), а также программистами и теми, у кого аллергия к любому программированию.
5. Добиться кардинального улучшения качества программного обеспечения по критерию «понимаемость алгоритмов и программ».

ДРАКОН начал частично применяться в программе МКС "Буран". И имел успех, но поскольку проект уже близился к заверщению ДРАКОН не являлся основным языком и использовался в основном "на бумаге", т.е. как язык описания алгоритмов во время общения специалистов между собой. Но работы по автоматизации графического языка велись. К сожалению программа МКС "Буран" была в одночасье закрыта. ДРАКОН переживал не лучшие времена, в целом на его разработку ушло 15 лет, но возник и на драконьей улице праздник. Этот праздник назывался проект Sea Launch. В проекте участвовали США, Норвегия, Россия и Украина. Пуски ракет производились с плавучей стартовой платформы, размещенной на экваторе в западной части Тихого океана в районе островов Кирибати. Управление пуском осуществлялось с находящегося поблизости сборочно-командного судна. Для каждого пуска стартовая платформа и сборочно-командное судно совершали морской рейс с базы, расположенной на западном побережье США, к островам Кирибати, а затем возвращались обратно. Результаты применения драконьей технологии оказались блестящими. Они превзошли все ожидания. После этого драконья технология использовалась в российско-французском космическом проекте «Фрегат», а также при модернизации ракеты-носителя «Протон-М». Результаты были стабильно высокими и руководство Пилюгинского центра приняло решение использовать драконью технологию во всех последующих проектах.

Я не историк космонавтики, хотя и работал когда-то в стенах РКК "Энергия" . И возможно, я несколько исказил какие-то факты или намерения людей. То что написано было услышано мною от разных людей и в разное время, а что-то было найдено в книгах и Сети. Проще говоря это моя компиляция истории развития языка ДРАКОН. Но бесспорен только один факт. ДРАКОН, как графический язык и как среда разработки, имел значительный успех в очень крупных проекта. Основываясь на примере ДРАКОНа я хочу поставить под сомнение утверждение некоторых коллег в этом форуме о том, что графические языки пригодны лишь для наглядного предствления простых задач.

Поищите к гугле информацию и проектах "Буран" и "Sea Launch" и их программном обеспецении. Это по меньшей мере просто интересно .

С Уважением,
md034t