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

Д>>правда? Вот я смотрю на один средненький метод, который занимает примерно один экран, и думаю — и ЭТО очень много информации?

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

А вот если его переписать на PEL, то площади он займет еще больше. Ну и что это вообще докажет?

Дарней wrote:

> C>Причина очень простая — с исходником работать удобнее.
> Просто потому, что нет удобных средств синхронизации между исходниками
> и диаграммами.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

B>Здравствуйте, Dyoma, Вы писали:
D>>Программировать обычно удобнее с текстом кода, а не с картинкой.
B>Даже с лисповым (текстом кода)?

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

Если же вернуться из далекого прошлого в настоящее, когда програмеры уже зажрались. И нам мало навороченной синтаксической подсветки, а хотим работать с кодом как с картинкой, и при том еще и красивой. То удобное решение стоит искать не в удобном IDE для Lisp, а в вообще удобном языке. А анахронизмам место в музее истории программирования.

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

Д>Зря ты смеешься. Я бы хотел иметь возможность представить возможные пути исполнения проги в виде графа — это сильно упростило бы жизнь в некоторых случаях.

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

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

AVK>Ты всерьез не понимаешь отличие исходников от реального здания или поспорить хочется?
Очень-очень ИМХО, спор случайно зашел не в то русло. Причем тут исходники, их редактор визуализирует просто замечательно. Визуализировать (возможно) нужно — потоки данных, зависимости модулей, иерархии классов и т.д., все знания о предметной области , которые разработчик отражает в исходном коде. Кто сказал, что понимать их можно по-разному? Есть принятые однозначные проектные решения, есть семантика языка программирования, написан однозначный программный код. Единственная проблема с ним — на него нельзя взглянуть с высоты птичьего полета, он слишком детален и занимает много места на экране. Я не агитирую за визуальное программирование, я просто хотел обратить внимание на тот момент, что аналогия между зданием и исходниками действительно неудачная, но между трехмерной моделью здания и некоторой моделью предметной области, уже отраженной в коде, но визуализированной более наглядно, — вполне хорошая аналогия.

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

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

DG>имхо, просматривать/анализировать, иногда даже рефакторить код — удобнее в визуальном виде.
DG>писать код — удобнее в текстовом виде

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

Ага. Можно, например, сделать так...
Хранить исходники в виде ХМЛ-я . Далее иметь несколько динамических конверторов в более удобное для представления и редактирования форматы. Хотим исхдник на C# — пожалуйста. Хотим на Лиспе — нет проблем! Хотим графическое представление — вуаля!

А так как основной исходник тоже текст, то и сорс-котролем проблем нет.

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

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

Это не визуальное программирование неудобно, а существующие средства для визуального программирования неудобны
Человеку куда удобнее мыслить не буквами и не цифрами, а картинками — это факт.

C>Угу, у нас Оракулоиды на него матеряться сейчас — надоело заниматься
C>вождением мышки.

имхо, просматривать/анализировать, иногда даже рефакторить код — удобнее в визуальном виде.
писать код — удобнее в текстовом виде

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

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

Д>Это не визуальное программирование неудобно, а существующие средства для визуального программирования неудобны
Д>Человеку куда удобнее мыслить не буквами и не цифрами, а картинками — это факт.

Осторожно, тема может превратиться в "Книги vs Кино"

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

AVK>Некорректная аналогия. В случае здания чертеж предлагает визуальный аналог реального объекта, пусть и снабженный дополнительной информацией. В случае ПО такого реального объекта нет, поэтому чертежи создать невозможно.

Данные — вполне реальный объект, как и сам код приложения.

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

Д>Данные — вполне реальный объект, как и сам код приложения.

Ага. Взвесьте мне пол-кило данных, пожалуйста.

Д>PS Насколько мне известно, ученые тратят немало усилий на визуализацию данных. Странно, зачем? Ведь простые таблицы текста и цифр куда информативнее, как мне только что доказали

Учёные вообще тратят много усилий.
Примерно с той же целью и эффектом, что и мы с Вами сейчас.
Работа у них такая .

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

Д>>Данные — вполне реальный объект, как и сам код приложения.

OT>Ага. Взвесьте мне пол-кило данных, пожалуйста.

солнечный свет ты тоже взвешивать будешь?

OT>Учёные вообще тратят много усилий.
OT>Примерно с той же целью и эффектом, что и мы с Вами сейчас.
OT>Работа у них такая .

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

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

не надо подменять понятия: "сделали возможным компьютер" ещё не значит "сделали компьютер". Уже давно "сделали возможным" добывание электричества посредством ядерного синтеза. Нам от этого теплее? И н-мерное пространство уже давно "сделали возможным", но никто туда почему-то не гуляет.
Технически достижимые результаты научных открытий составляют мизерную часть этих самых открытий. Это не значит, что не стоит их уважать, считая основой. Это значит, что не стоит подменять технический подход научным.

Д>>>Данные — вполне реальный объект, как и сам код приложения.
OT>>Ага. Взвесьте мне пол-кило данных, пожалуйста.
Д>солнечный свет ты тоже взвешивать будешь?

солнечный свет — рельный объект. данные — виртуальный.

The MATRIX has you.

Д>а что, технический подход имеет принципиальные отличия от научного? (в рассматриваемом нами вопросе, конечно)

Технический подход направлен на получение ощутимого результата, а научный подход направлен на осуществление научного подхода. Только и всего.
Можно сколько угодно рисовать графы и кубики — никто не запрещает вашей мысли витать в облаках.

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

D>Программировать обычно удобнее с текстом кода, а не с картинкой. Кода существенно больше влезает на экран

С другой стороны, когда тебе нужно найти нужный метод в файле — что тебе удобнее, исходники или навигатор по коду?
И вообще, одно другого не исключает. Истина, как всегда, где-то посредине.

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

AVK>Некорректная аналогия. В случае здания чертеж предлагает визуальный аналог реального объекта, пусть и снабженный дополнительной информацией. В случае ПО такого реального объекта нет, поэтому чертежи создать невозможно.

Данные — вполне реальный объект, как и сам код приложения.

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

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

ГА>Что такое ARIS, не знаю.

Это, так сказать, описание предметной области/бизнес процессов с помошью блок схемы, со своими законами рисования.

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

Д>Зря ты смеешься. Я бы хотел иметь возможность представить возможные пути исполнения проги в виде графа — это сильно упростило бы жизнь в некоторых случаях.

Визуалицация как, там графы всякие, очень полезная вещь в качестве одного из представлений кода. Широко распостранены такие визуализации как
— дерево файловой системы
— представления иерархий классов разными способами. Разные способы приходится использовать в языках с хоть каким-то множественным наследованием.
— различные control-flow (дерево вызываемых/вызывающих методов)

Программировать обычно удобнее с текстом кода, а не с картинкой. Кода существенно больше влезает на экран

Cyberax wrote:

>> Человеку куда удобнее мыслить не буквами и не цифрами, а картинками —
>> это факт.
> Мне, например, не удобнее — так что не факт.

Чисто для заметки: мне всегда в школе и университете не нравились
сложные геометрические чертежи, поэтому большую часть задач я решал
методом координат (а аналитическая геометрия была моим любимым предметом).

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

R3>Ну он может и не позволяет, но разве трудно преобразовать C# в VB.NET?
Трудно. Ну, вот к примеру, как ты собираешься преобразовать в VB.NET вот такой код на C#:

public interface ITest
{ 
  int A { get; }
}
public class C1 : ITest
{
  public int A { get { return 1; } }
}
public class C2: C1, ITest
{
  int ITest.A { get { return 2; } }
}

?

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

OS>IMHO: next breakthrough — полноценное визуальное программирование.

Ага. Истенная 3D визуализация процесса можификации переменной.

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

Д>Зря ты смеешься. Я бы хотел иметь возможность представить возможные пути исполнения проги в виде графа — это сильно упростило бы жизнь в некоторых случаях.

Дык это уже было. Нас учили программировать с блок-схем. Я их запросил почти сразу. Даже небольшая программа в них занимает тонны места. Да и потом получается страшная вещь. Программы получаеются как будто на ассемблере или в виде конечных автоматов. Потом прочесть их очень не просто.

Кстати, для Жлабэйсика даже есть работающий коммерческий проект визуального кодирования. Его много рекламировали в англоязычном МСДН Мэгэзин, но я так и не встретил ни одного человека кто бы писал на этом деле. Но выглядило все красиво. Икончки... линии между ними...

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

C>Мне, например, не удобнее — так что не факт.

исключение только подтверждает правило

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

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

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

Кстати, код тоже проще читать если он грамотно структурирован, разбит процедурами или размечен разными #region-ами как в C# и VB.NET. Я вот стараюсь или не писать большие методы вовсе, или размечать их регионами. Это и мне урощает поиск нужного участка кода, и другим чтение упрощает.

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

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

Мне нравится Together, например. Хотя недостатков у него пока что целая куча

VD>Кстати, в некоторых ситациях визуализация очень хорошо подходит. Например, если есть некий декларативный язык вроде EBNF, то его можно представить визуально. Я тут давича видел забавную утилитку такого рода. Вот если кому интересно гляньте EBNF Visualizer. Это всего лишь эдакий изыск. Работать с ним нельзя (ниделает он почти ничего), но на его базе можно было бы создать визуальный редактор EBNF-описаний для какой-нибудь CocoR или ANTLR. Одна только навигация по глику уже круто. Вот только изменять это дело непоятно как. Хотя можно банально внизу разместить окно с обычным текстовым редактором и синхронизироваться с положением правил в тексте. А там уже просто перепарсивать все это дело.

VD>Но это возможно именно потому что EBNF декларативный язык! Для императивных я такое представляю с трудом. Хотя... в той же VS 2005 есть "я-ля UML"-редакторв который позволяет формировать диаграмы классов. В нем можно и новый класс создать, и текущий изменить, и метод добавить... Может это и есть то свмое будующее визуального программирования? Ну, когда сам код все же является кодом, но его можно тем или иным образом представить визуально.

Есть еще визуальный редактор для схем в XML Spy. Очень удобная штука, ИМХО.

mishaa wrote:

> C>Причина очень простая — с исходником работать удобнее.
> Даже в случае работы с несколькими параллельными потоками?

Тем более в случае с параллельными потоками.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

VD>Ага. Можно, например, сделать так...
VD>Хранить исходники в виде ХМЛ-я . Далее иметь несколько динамических конверторов в более удобное для представления и редактирования форматы. Хотим исхдник на C# — пожалуйста. Хотим на Лиспе — нет проблем! Хотим графическое представление — вуаля!

XML? мама, роди меня обратно
база данных будет куда эффективнее и уместнее

VD>А так как основной исходник тоже текст, то и сорс-котролем проблем нет.

лучше уж адаптировать сорс-контрол для работы с базами данных

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

VD>Ага. Можно, например, сделать так...
VD>Хранить исходники в виде ХМЛ-я . Далее иметь несколько динамических конверторов в более удобное для представления и редактирования форматы. Хотим исхдник на C# — пожалуйста. Хотим на Лиспе — нет проблем! Хотим графическое представление — вуаля!

а вообще, идея "один код — много представлений" это правильно, я сам давно уже про это думал
хотя представить один и тот же код и в виде C#, и в виде Lisp не получится — слишком разные языки. Но фанаты := наконец то не смогут больше ни к чему докопаться

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

S>Лично мне неизвестна такая теория. Нет, я понимаю, что с точки зрения понятия вычислимости все языки совершенно одинаковы.

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

S>Но нас то интересует не формальное определение эквивалентного алгоритма. Мы ожидаем увидеть те же (ну или разумно близкие) элементы языка.

вот с "разумно близкими" конструкциями уже намного сложнее. С другой стороны, зачем вообще нужны два разных языка, если их конструкции почти ничем не отличаются?

S>Особенно здорово, если это неязыковые конструкции.

не совсем понял. ты про зависимости от внешних библиотек?

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

Д>>Теоретически можно преобразовать из любого языка в любой другой. Например, из C# в C++

VD>Очень теоритически. Основная проблема будет управление жизнью объектов.
Или метапрограммирование.

А вообще Prolog — тоже машина Тьюринга. Но очень интересно посмотреть на реализацию сокета в исполнении сего языка.

С уважением, Gleb.

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

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

Д>гениально! остается только удивляться, почему все рисуют графы, а не представляют в виде списков смежности

я не рисую
и не знаю ни одного программиста, который рисует.

Д>А с каких это пор точкой обозначают реализацию свойства?

оговорился. наверное понятно.

Д>аналогия абсолютно та. Архитектуру ПО не просто так называют именно этим словом.

а причём архитектура ПО?
повторюсь, что о проектировании речи нет. Конструирование ПО в строительстве аналогии не имеет.
А вообще мне кажется, что мы развели слишком большой флейм по несущественному (is null ) вопросу. Не обижайтесь если не увидите от меня дальнейших ответов.

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

OT>не надо подменять понятия: "сделали возможным компьютер" ещё не значит "сделали компьютер". Уже давно "сделали возможным" добывание электричества посредством ядерного синтеза. Нам от этого теплее? И н-мерное пространство уже давно "сделали возможным", но никто туда почему-то не гуляет.
OT>Технически достижимые результаты научных открытий составляют мизерную часть этих самых открытий. Это не значит, что не стоит их уважать, считая основой. Это значит, что не стоит подменять технический подход научным.

а что, технический подход имеет принципиальные отличия от научного? (в рассматриваемом нами вопросе, конечно)

OT>солнечный свет — рельный объект. данные — виртуальный.

И что, это как-то мешает представлять данные графически?

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

AVK>И сфотографировать исходники нельзя.

В принципе, можно. С экрана компьютера.

Как бы не смешно это звучало, имхо, была пару лет назад история с промышленым шпионажем то ли в IBM, то ли в Intel, но это не важно. Короче, один инженер решил продать внутреннюю документацию по новой разработке (кажется микропроцессоре). Но с работы унести распечатки или другие носители с информацией он не мог. А из дому мог только просматривать эту документацию, не имея возможности ни распечатать их, ни сохранить куда-нибудь. Так он придумал простое решение -- записывал на видео информацию с экрана компьютера. И именно эту видеозапись он и собирался продать.

В общем, к вашей с Дарнеем дискуссии это отношения не имеет. Просто так, навеяло

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

OT>Можно сколько угодно рисовать графы и кубики — никто не запрещает вашей мысли витать в облаках.

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

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

AVK>>>И сфотографировать исходники нельзя.

E>>В принципе, можно. С экрана компьютера.

AVK>Только вот сфотографируешь ты не сами исходники, а их представление каким либо софтом.

Что-то в твоих словах, определенно есть . Если продолжать думать в этом направлении... то результатом может быть:

"Ты суслика видишь? Нет? А он есть..." (c)

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

Дарней wrote:

> C>Это потому, что покоящихся фотонов не существует — они всегда движутся
> C>со скоростью света.
> вероятно, так и есть
> а как их можно взвесить?

По формуле E=mc^2

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

VD>Ага. Истенная 3D визуализация процесса можификации переменной.

Зря ты смеешься. Я бы хотел иметь возможность представить возможные пути исполнения проги в виде графа — это сильно упростило бы жизнь в некоторых случаях.

Дарней wrote:

> VD>Ага. Истенная 3D визуализация процесса можификации переменной.
> Зря ты смеешься. Я бы хотел иметь возможность представить возможные
> пути исполнения проги в виде графа — это сильно упростило бы жизнь в
> некоторых случаях.

Эта... Баян однако, было 30 лет назад — под названием flowcharts. Сейчас
почти померло. Единственная область, в которой они активно используются
— это reverse engineering. Еще используются во всяких flow diagram в
Oracle'овских бизнес-приложениях (наших Ораклистов как раз заставили
мышкой рисовать в нем — ох уж и ругаются) и т.п.

Причина очень простая — с исходником работать удобнее.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Эта... Баян однако, было 30 лет назад — под названием flowcharts. Сейчас
C>почти померло. Единственная область, в которой они активно используются
C>- это reverse engineering. Еще используются во всяких flow diagram в
C>Oracle'овских бизнес-приложениях (наших Ораклистов как раз заставили
C>мышкой рисовать в нем — ох уж и ругаются) и т.п.

Ну да, как раз reverse engineering я имел в виду. Хотя при поиске багов это тоже может быть очень полезно.

C>Причина очень простая — с исходником работать удобнее.

Просто потому, что нет удобных средств синхронизации между исходниками и диаграммами.

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

VD>Дык это уже было. Нас учили программировать с блок-схем. Я их запросил почти сразу. Даже небольшая программа в них занимает тонны места. Да и потом получается страшная вещь. Программы получаеются как будто на ассемблере или в виде конечных автоматов. Потом прочесть их очень не просто.

Во времена господства goto это была вполне удобная вещь. Потом они стали просто не нужны.

VD>Кстати, для Жлабэйсика даже есть работающий коммерческий проект визуального кодирования. Его много рекламировали в англоязычном МСДН Мэгэзин, но я так и не встретил ни одного человека кто бы писал на этом деле. Но выглядило все красиво. Икончки... линии между ними...

Красиво и функционально, к сожалению, не синонимы

Дарней wrote:

> C>Блин, да они есть уже 20 лет. Просто визульное программирование
> неудобно
> C>(за исключением некоторых специфичных областей).
> Это не визуальное программирование неудобно, а существующие средства
> для визуального программирования неудобны
> Человеку куда удобнее мыслить не буквами и не цифрами, а картинками —
> это факт.

Мне, например, не удобнее — так что не факт.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

Д>Это не визуальное программирование неудобно, а существующие средства для визуального программирования неудобны
Д>Человеку куда удобнее мыслить не буквами и не цифрами, а картинками — это факт.

Человеку удобнее мыслить понятиями, своими собственными. А читать удобнее не прибега к скролингу. Текстовое представление исходников дает возможность запихать очень много информации на небольшую площадь.
И еще один довод в пользу текста. Каждое средство разработки требует навыков работы с ним. Набирать текст умеют все, и делаю это довольно быстро. А водить по экрану мышкой, занятие мало эфективное, в смысле скорости передаци информации (запихивание своих мыслей в комп).

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

D>Текстовое представление исходников дает возможность запихать очень много информации на небольшую площадь.

правда? Вот я смотрю на один средненький метод, который занимает примерно один экран, и думаю — и ЭТО очень много информации?

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

Д>правда? Вот я смотрю на один средненький метод, который занимает примерно один экран, и думаю — и ЭТО очень много информации?

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

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

Д>С другой стороны, когда тебе нужно найти нужный метод в файле — что тебе удобнее, исходники или навигатор по коду?
Д>И вообще, одно другого не исключает. Истина, как всегда, где-то посредине.

Если мне нужен метод этого класса, то как правило я использую "плоский" навигатор (a-la панелька far manager, вложенные классы — директории, методы — файлы), реже древовидный (таже метафора файловой системы, но в виде дерева). Единственное редактирования, которое я хотел бы (но не реализовано ) с помощью этих навигаторов делать, это двигать классы\методы вверх\вниз по файлу.
Если же мне нужена ссылка на метод другого класса, то я использую инкрементальный текстовый поиск. А когда нахожу первую, говорю IDE что мне нужна такая же следующая/предыдущая. Ксати в первом случае — поиск метода текущего класса, я октрываю навигатор и опять же ищу инкрементальным текстовым поиском.
Ксати в моей любимой IDE (Idea) есть другой способ и многие им пользуются. В редакторе, одним шорткатом сворачиваются все определения методов, после чего сам текст превращается в навигатор

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

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

Д>А вот если его переписать на PEL, то площади он займет еще больше. Ну и что это вообще докажет?

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

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

D>Ксати в моей любимой IDE (Idea) есть другой способ и многие им пользуются. В редакторе, одним шорткатом сворачиваются все определения методов, после чего сам текст превращается в навигатор

Вот уже и первый шаг от plain text к графическому представлению

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

D>Имхо, картинки (и другие альтернативы текста) полезны, когда с их помощью можно посмотреть на код, выкидывая большую часть информации, не интересной в данный момент.

Ты совершенно прав Чтобы, к примеру, получить общую информацию об архитектуре.

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

D>Ксати в моей любимой IDE (Idea) есть другой способ и многие им пользуются. В редакторе, одним шорткатом сворачиваются все определения методов, после чего сам текст превращается в навигатор

Кстати #region в VS удобная штука. Можно эмулировать Smalltalk-овые протоколы

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

Д>Это не визуальное программирование неудобно, а существующие средства для визуального программирования неудобны
Д>Человеку куда удобнее мыслить не буквами и не цифрами, а картинками — это факт.

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

Кстати, в некоторых ситациях визуализация очень хорошо подходит. Например, если есть некий декларативный язык вроде EBNF, то его можно представить визуально. Я тут давича видел забавную утилитку такого рода. Вот если кому интересно гляньте EBNF Visualizer. Это всего лишь эдакий изыск. Работать с ним нельзя (ниделает он почти ничего), но на его базе можно было бы создать визуальный редактор EBNF-описаний для какой-нибудь CocoR или ANTLR. Одна только навигация по глику уже круто. Вот только изменять это дело непоятно как. Хотя можно банально внизу разместить окно с обычным текстовым редактором и синхронизироваться с положением правил в тексте. А там уже просто перепарсивать все это дело.

Но это возможно именно потому что EBNF декларативный язык! Для императивных я такое представляю с трудом. Хотя... в той же VS 2005 есть "я-ля UML"-редакторв который позволяет формировать диаграмы классов. В нем можно и новый класс создать, и текущий изменить, и метод добавить... Может это и есть то свмое будующее визуального программирования? Ну, когда сам код все же является кодом, но его можно тем или иным образом представить визуально.

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

VD>Но это возможно именно потому что EBNF декларативный язык! Для императивных я такое представляю с трудом.

Например — "показать, какие классы использует данный класс"
или — "показать, какие типы и методы использует данный метод"

Здравствуйте, Dyoma, Вы писали:
D>Программировать обычно удобнее с текстом кода, а не с картинкой.
Даже с лисповым (текстом кода)?

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


C>Причина очень простая — с исходником работать удобнее.

Даже в случае работы с несколькими параллельными потоками?

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


C>Тем более в случае с параллельными потоками.

Эх, если бы . Посмотрите на маленький кусок кода "волшебного" языка BPEL

<flow>
 <receive name="receive1" partner="customer" 
 portType="apns:loanApprovalPT" 
 operation="approve" container="request"
 createInstance="yes">
 <source linkName="receive-to-assess"
 transitionCondition="bpws:getContainerData('request', 'amount')&lt;10000"/>
 <source linkName="receive-to-approval"
 transitionCondition="bpws:getContainerData('request', 'amount')&gt;=10000"/>
 </receive>

 <invoke name="invokeAssessor" partner="assessor" 
 portType="asns:riskAssessmentPT" 
 operation="check"
 inputContainer="request" 
 outputContainer="riskAssessment">
 <target linkName="receive-to-assess"/>
 <source linkName="assess-to-setMessage" 
 transitionCondition="bpws:getContainerData('riskAssessment', 'risk')='low'"/>
 <source linkName="assess-to-approval" 
 transitionCondition="bpws:getContainerData('riskAssessment', 'risk')!='low'"/>
 </invoke>

 <assign name="assign">
 <target linkName="assess-to-setMessage"/>
 <source linkName="setMessage-to-reply"/>
 <copy>
 <from expression="'yes'"/>
 <to container="approvalInfo" part="accept"/>
 </copy>
 </assign>

 <invoke name="invokeapprover" 
 partner="approver" portType="apns:loanApprovalPT" 
 operation="approve" 
 inputContainer="request" 
 outputContainer="approvalInfo">
 <target linkName="receive-to-approval"/>
 <target linkName="assess-to-approval"/>
 <source linkName="approval-to-reply" />
 </invoke>

 <reply name="reply" partner="customer" portType="apns:loanApprovalPT" 
 operation="approve" container="approvalInfo">
 <target linkName="setMessage-to-reply"/>
 <target linkName="approval-to-reply"/>
 </reply>
 </flow>

Все теги внутри flow запускаются параллельно. Source и target грубо говоря отражают зависимости, зависимые(те что с target'ом) теги не выполняются пока все source теги не отработают. Текст абсолютно нечитабелен. А вот если нарисовать направленный граф, все становится предельно ясно.

Или дело в тексте? Как можно аналогичную функциональность выразить просто и понятно в текстовом виде?

P.S. Извините за кривое форматирование xml'я — пишу с кпк.

mishaa wrote:

> C>Тем более в случае с параллельными потоками.
> Эх, если бы . Посмотрите на маленький кусок кода "волшебного" языка BPEL

Есть такой древний язык — make:

target: sub1 sub2 sub3
    do something

sub1: something
    blah-blah

Может выполняться конурентно.

> Все теги внутри flow запускаются параллельно. Source и target грубо
> говоря отражают зависимости, зависимые(те что с target'ом) теги не
> выполняются пока все source теги не отработают. Текст абсолютно
> нечитабелен. А вот если нарисовать направленный граф, все становится
> предельно ясно.

Угу, у нас Оракулоиды на него матеряться сейчас — надоело заниматься
вождением мышки.

> Или дело в тексте? Как можно аналогичную функциональность выразить
> просто и понятно в текстовом виде?

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Угу, у нас Оракулоиды на него матеряться сейчас — надоело заниматься
C>вождением мышки.

Угу аналогично.... а че делать — стандарт, блин, визуального программирования....

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

Д>хотя представить один и тот же код и в виде C#, и в виде Lisp не получится — слишком разные языки.

Проблемы уже в том, что в C++ например можно нахождение чисел Фибоначи реализовать циклично и рекурсивно.
А в Лиспе — решается по третьему варианту.

С уважением, Gleb.

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

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

Д>а вообще, идея "один код — много представлений" это правильно, я сам давно уже про это думал
Д>хотя представить один и тот же код и в виде C#, и в виде Lisp не получится — слишком разные языки. Но фанаты := наконец то не смогут больше ни к чему докопаться

Проблема в том, что абстракция хорошо изображающаяся в одном представлении, погано выглядит в другом... т.е. получается все равно если код написан в этом представлении нем и писать дальше надобно. Где-то тут валяется токик про uml, в котором высказывалось замечание, что пользователи генерирующие по uml си код хотят от uml-ля одного, а пользователи работающие с C++, совсем другого.

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

M>Где-то тут валяется токик про uml, в котором высказывалось замечание, что пользователи генерирующие по uml си код хотят от uml-ля одного, а пользователи работающие с C++, совсем другого.

UML очень сильно заточен под ООП. понятно, что для работы с С он не очень приспособлен

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

VD> Далее иметь несколько динамических конверторов в более удобное для представления и редактирования форматы. Хотим исхдник на C# — пожалуйста. Хотим на Лиспе — нет проблем!

Ну вроде эту проблему семейство языков NET'а как раз и решило.

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

VD>> Далее иметь несколько динамических конверторов в более удобное для представления и редактирования форматы. Хотим исхдник на C# — пожалуйста. Хотим на Лиспе — нет проблем!

R3>Ну вроде эту проблему семейство языков NET'а как раз и решило.

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

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

VD>... А вот возможности преобразовывать одни в другие он не позволяет

Ну он может и не позволяет, но разве трудно преобразовать C# в VB.NET?

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

S>Трудно. Ну, вот к примеру, как ты собираешься преобразовать в VB.NET вот такой код на C#:

Ясно. Был не прав. Просто я думал о мелочах.

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

VD>>... А вот возможности преобразовывать одни в другие он не позволяет

R3>Ну он может и не позволяет, но разве трудно преобразовать C# в VB.NET?

Как сказать... Проще конечно чем С++ в Лисп, но все же задача не тривиальная. По контексту не решается.

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

R3>>Ну он может и не позволяет, но разве трудно преобразовать C# в VB.NET?
S>Трудно. Ну, вот к примеру, как ты собираешься преобразовать в VB.NET вот такой код на C#:
S>

S>public interface ITest
S>{ 
S>  int A { get; }
S>}
S>public class C1 : ITest
S>{
S>  public int A { get { return 1; } }
S>}
S>public class C2: C1, ITest
S>{
S>  int ITest.A { get { return 2; } }
S>}
S>

S>?

Что то я не понял. Можно по подробнее? А то я не большой знаток нового Васика.

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

VD>Что то я не понял. Можно по подробнее? А то я не большой знаток нового Васика.
А что тут подробнее. Басик запрещает повторную реализацию интерфейсов в классах-потомках.

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

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

VD>>Что то я не понял. Можно по подробнее? А то я не большой знаток нового Васика.
S>А что тут подробнее. Басик запрещает повторную реализацию интерфейсов в классах-потомках.

Попробовал...

Module Module1
    Sub Main()
        Dim itf As ITest = New B

        itf.F()
    End Sub
End Module

Interface ITest
    Sub F()
End Interface


Class A
    Implements ITest

    Public Sub F() Implements ITest.F
        Console.WriteLine("A::ITest.F")
    End Sub
End Class

Class B
    Inherits A
    Implements ITest

    Public Sub F1() Implements ITest.F
        Console.WriteLine("B::ITest.F")
    End Sub
End Class

Все скомпилировалось, но с варнингом:

E:\...\Module1.vb(26) : warning BC42015: 'ITest.F' is already implemented by the base class 'A'. Re-implementation of sub assumed.

Выполняется верно:

B::ITest.F

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

VD>Попробовал...
VD>Все скомпилировалось, но с варнингом:
VD>

E:\...\Module1.vb(26) : warning BC42015: 'ITest.F' is already implemented by the base class 'A'. Re-implementation of sub assumed.

VD>Выполняется верно:
Хм. Наверное, я что-то напутал. Тут вроде на днях как раз разговор на эту тему был... Может, это VB.NET 1.1?
Тогда еще шансы есть. Вообще говоря, у меня сложилось впечатление, что нет никакой гарантии того, что все фишки .Net будут поддерживаться произвольным компилятором. А тогда есть риск не суметь произвести конверсию тудыть-сюдыть. Ну вот там, к примеру, если бейсик не содержит слов аналогичным checked/unchecked, то ему будет крайне трудно отобразить соответствующие мсил-команды.

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

S>Хм. Наверное, я что-то напутал. Тут вроде на днях как раз разговор на эту тему был... Может, это VB.NET 1.1?

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

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

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

VD>Кстати, код тоже проще читать если он грамотно структурирован, разбит процедурами или размечен разными #region-ами как в C# и VB.NET. Я вот стараюсь или не писать большие методы вовсе, или размечать их регионами. Это и мне урощает поиск нужного участка кода, и другим чтение упрощает.

Кстати если бы в студии схлопанные участки кода отображались бы прямоугольничком, а схлопанный класс UML блоком с методами и свойствами, было бы наверное немножко удобнее. Подкинуть им что-ли идейку

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

S>Здравствуйте, Real 3L0, Вы писали:

R3>>Ну он может и не позволяет, но разве трудно преобразовать C# в VB.NET?
S>Трудно. Ну, вот к примеру, как ты собираешься преобразовать в VB.NET вот такой код на C#:

Теоретически можно преобразовать из любого языка в любой другой. Например, из C# в C++
Другой вопрос, что преобразования "1 в 1" не получится, ряд конструкций придется эмулировать

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

S>Здравствуйте, Real 3L0, Вы писали:

R3>>Ну он может и не позволяет, но разве трудно преобразовать C# в VB.NET?
S>Трудно. Ну, вот к примеру, как ты собираешься преобразовать в VB.NET вот такой код на C#:

Теоретически можно преобразовать из любого языка в любой другой. Например, из C# в C++
Другой вопрос, что преобразования "1 в 1" не получится, ряд конструкций придется эмулировать

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

Д>Теоретически можно преобразовать из любого языка в любой другой. Например, из C# в C++
Лично мне неизвестна такая теория. Нет, я понимаю, что с точки зрения понятия вычислимости все языки совершенно одинаковы.
Но нас то интересует не формальное определение эквивалентного алгоритма. Мы ожидаем увидеть те же (ну или разумно близкие) элементы языка.

Д>Другой вопрос, что преобразования "1 в 1" не получится, ряд конструкций придется эмулировать

Особенно здорово, если это неязыковые конструкции.

Здравствуйте, Чипсет, Вы писали:
Ч>Кстати если бы в студии схлопанные участки кода отображались бы прямоугольничком, а схлопанный класс UML блоком с методами и свойствами, было бы наверное немножко удобнее. Подкинуть им что-ли идейку
А они что-то навроде того на после-orcas версию и планируют. Там вообще не UI а улет!

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

Д>Теоретически можно преобразовать из любого языка в любой другой. Например, из C# в C++

Очень теоритически. Основная проблема будет управление жизнью объектов.

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

Д>>Теоретически можно преобразовать из любого языка в любой другой. Например, из C# в C++

VD>Очень теоритически. Основная проблема будет управление жизнью объектов.

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

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

GZ>А вообще Prolog — тоже машина Тьюринга. Но очень интересно посмотреть на реализацию сокета в исполнении сего языка.

с прлогом я мало знаком, поэтому сказать не могу. Что касается ФЯ, то на них даже целые ОСи вполне благополучно пишут.

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

Д>>исключение только подтверждает правило
OT>Тут скорее надо разобраться: что правило, а что — исключение.
OT>Насколько я понимаю, плоско мыслят сейчас только маркетологи, недалёкие менеджеры и несчастные программисты, воспитаные на блок-схемах.

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

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

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

да черт с ними, с блок-схемами. Свою полезность они уже давно исчерпали.
а что значит "плоско мыслят"?

Д>а что значит "плоско мыслят"?

Значит — мыслят на плоскости.
Не знаю как Вам, а лично мне, чтобы отобразить в виде плоской схемы моё понимание какой-либо сложной проблемы, надо сотворить с этим пониманием что-то вроде школьного препарирования лягушки, когда цельное понятие кромсается на части и распластывается на плоскости. Понимание от такого отображения снижается, а улучшается только демонстративность — смотрите сколько красивого наваял. Тех кто не понимает, впечатляет очень. А код — это просто код.
Это как отличие литературы от кино. Полные образы против жёстко ограниченных.

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

VD>Здравствуйте, O-Sam, Вы писали:

OS>>IMHO: next breakthrough — полноценное визуальное программирование.

VD>Ага. Истенная 3D визуализация процесса можификации переменной.

Дык. Про визуализацию — это к гадалке не ходи. Раз UI и представление кода они в графическом виде, визуализация будет присутствовать и развиваться.
Но основной вопрос — что причина, а что следствие... Имхо визуализация особой роли не играет. Вот шахматисты, наработав приемы могут играть в шахматы без всякой "визуализации".

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

OT>Значит — мыслят на плоскости.
OT>Не знаю как Вам, а лично мне, чтобы отобразить в виде плоской схемы моё понимание какой-либо сложной проблемы, надо сотворить с этим пониманием что-то вроде школьного препарирования лягушки, когда цельное понятие кромсается на части и распластывается на плоскости.

а про трехмерную проекцию ты никогда не слышал?

OT>Это как отличие литературы от кино. Полные образы против жёстко ограниченных.

Какой объем текста понадобится, чтобы подробно описать архитектуру дома? Сколько времени понадобится, чтобы по этому описанию составить цельное представление об этой архитектуре?

Д>а про трехмерную проекцию ты никогда не слышал?

вот это и есть лягушка.

Д>Какой объем текста понадобится, чтобы подробно описать архитектуру дома? Сколько времени понадобится, чтобы по этому описанию составить цельное представление об этой архитектуре?

я по образованию — конструктор-механик(почти )
Встречный вопрос: сколько чертежей нужно, чтобы полностью раскрыть проект, реализованый в 3х-мерном виде в том же архикаде?
Вопрос риторический (у меня родители — строители).

Но аналогия, честно говоря хромает. 3хмерный образ — всё равно визуальный, в архитектуре без этого никак. А вот материалы, требования и др. отобразить сложнее. Без текстов никуда.

Отвыкайте мыслить плоско. Так на плоскости и останетесь.

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

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

OT>Встречный вопрос: сколько чертежей нужно, чтобы полностью раскрыть проект, реализованый в 3х-мерном виде в том же архикаде?

а вы случаем не еврей?
в любом случае — не думаю, что больше (или хотя бы сравнимо по объему), чем аналогичное по информативности описание плоским текстом

OT>Без текстов никуда.

а никто и не предлагал выбрасывать текст вообще. Но это не значит, что надо писать ВСЕ текстом, как сейчас.

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

Ну тогда я полетел

Д>а вы случаем не еврей?
нет
но и не антисемит

Д>а никто и не предлагал выбрасывать текст вообще. Но это не значит, что надо писать ВСЕ текстом, как сейчас.

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

(мы здесь говорим не о проектировании, а именно о конструировании с точки зрения Макконелла)

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

OT>нет
OT>но и не антисемит

аналогично
и все-таки, ты будешь утверждать, что набор чертежей больше по объему, чем эквивалентное текстовое описание?

OT>в том-то и дело, что в случае визуального программирования, не настолько увеличивается уровень абстракции, чтобы в этом имелся какой-то смысл ИМХО

уровень абстракции — не увеличивается. зато увеличивается простота в понимании и уменьшается объем. этого мало?

Д>и все-таки, ты будешь утверждать, что набор чертежей больше по объему, чем эквивалентное текстовое описание?

думаю в тубус влезет довольно толстое текстовое описание
а, если серьёзно, то я уже ответил, что аналогия немного не та

OT>>в том-то и дело, что в случае визуального программирования, не настолько увеличивается уровень абстракции, чтобы в этом имелся какой-то смысл ИМХО

Д>уровень абстракции — не увеличивается. зато увеличивается простота в понимании и уменьшается объем. этого мало?

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

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

OT>думаю в тубус влезет довольно толстое текстовое описание

так и представляю себе прораба (или кто там еще) на стройке, который вытаскивает из тубуса объемистое описание, раскладывает и начинает вдумчиво его читать. недель так на n

OT>а, если серьёзно, то я уже ответил, что аналогия немного не та

аналогия абсолютно та. Архитектуру ПО не просто так называют именно этим словом.

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

гениально! остается только удивляться, почему все рисуют графы, а не представляют в виде списков смежности

OT>Сравните оператор "." и стрелку с одного края диаграммы на другой, с отображением того, что эта стрелка указывает на реализацию свойства.

А с каких это пор точкой обозначают реализацию свойства?

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

Д>и все-таки, ты будешь утверждать, что набор чертежей больше по объему, чем эквивалентное текстовое описание?

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

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

AVK>>Некорректная аналогия. В случае здания чертеж предлагает визуальный аналог реального объекта, пусть и снабженный дополнительной информацией. В случае ПО такого реального объекта нет, поэтому чертежи создать невозможно.

Д>Данные — вполне реальный объект, как и сам код приложения.

Данные может быть. Но речь то об архитектуре ПО.

Д>PS Насколько мне известно, ученые тратят немало усилий на визуализацию данных. Странно, зачем? Ведь простые таблицы текста и цифр куда информативнее, как мне только что доказали

Я говрил о том, что аналогия некудышная и ни о чем больше.

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

VD>Ага. Истенная 3D визуализация процесса можификации переменной.
а что тут написано?

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

AVK>Я говрил о том, что аналогия некудышная и ни о чем больше.

потому что нет "реального объекта"? Исходники существуют вполне физически, в виде файлов которые лежат на твоем или чьем-то еще винте.
А то, что их нельзя пощупать руками — это уже дело десятое.

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

Д>потому что нет "реального объекта"? Исходники существуют вполне физически, в виде файлов которые лежат на твоем или чьем-то еще винте.
Д>А то, что их нельзя пощупать руками — это уже дело десятое.

Ты всерьез не понимаешь отличие исходников от реального здания или поспорить хочется?

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

AVK>Ты всерьез не понимаешь отличие исходников от реального здания или поспорить хочется?

да, не понимаю. расскажи

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

Д>да, не понимаю. расскажи

Форма здания дана нам в ощущениях и изменить ее мы не в силах. Чертеж его, это всего лишь фотография, из которой выкинуто лишнее и добавлено нужное. А вот исходники каждый софт воспринимает как ему хочется. И сфотографировать исходники нельзя.

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

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

Д>>>Данные — вполне реальный объект, как и сам код приложения.

OT>>Ага. Взвесьте мне пол-кило данных, пожалуйста.

Д>солнечный свет ты тоже взвешивать будешь?

Если память не изменяет, электромагнитное поле имеет массу.

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

AVK>>И сфотографировать исходники нельзя.

E>В принципе, можно. С экрана компьютера.

Только вот сфотографируешь ты не сами исходники, а их представление каким либо софтом.

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

AVK>Форма здания дана нам в ощущениях и изменить ее мы не в силах. Чертеж его, это всего лишь фотография, из которой выкинуто лишнее и добавлено нужное.

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

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

B>Если память не изменяет, электромагнитное поле имеет массу.

масса покоя у фотона равна нулю
впрочем, я не специалист в физике, так что могу и ошибаться

Дарней wrote:

> B>Если память не изменяет, электромагнитное поле имеет массу.
> масса покоя у фотона равна нулю

Это потому, что покоящихся фотонов не существует — они всегда движутся
со скоростью света.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Это потому, что покоящихся фотонов не существует — они всегда движутся
C>со скоростью света.

вероятно, так и есть
а как их можно взвесить?

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

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

C>>Это потому, что покоящихся фотонов не существует — они всегда движутся
C>>со скоростью света.

Д>вероятно, так и есть
Д>а как их можно взвесить?

По отклонению в гравитационном поле. Так Энштейн свою теорию и проверил.

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

ГА>Очень-очень ИМХО, спор случайно зашел не в то русло. Причем тут исходники, их редактор визуализирует просто замечательно. Визуализировать (возможно) нужно — потоки данных, зависимости модулей, иерархии классов и т.д., все знания о предметной области , которые разработчик отражает в исходном коде.

Это ты про ARIS?

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

ГА>>Очень-очень ИМХО, спор случайно зашел не в то русло. Причем тут исходники, их редактор визуализирует просто замечательно. Визуализировать (возможно) нужно — потоки данных, зависимости модулей, иерархии классов и т.д., все знания о предметной области , которые разработчик отражает в исходном коде.
R3>Это ты про ARIS?
Да нет, я это мыслию по древу, ткскть .
Просто я в целом поддерживал позицию Дарнея, и зачем они с AndrewVK вдруг начали исходники с домами сравнивать, не понимаю, вот и вставил пару таньга.
Что такое ARIS, не знаю.

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

Д>а как их можно взвесить?

Например измерив момент импульса.

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

Д>Я бы хотел иметь возможность представить возможные пути исполнения проги в виде графа — это сильно упростило бы жизнь в некоторых случаях.

Вы будете смеяться, но такие средства есть.

Например, здесь

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

S>Вы будете смеяться, но такие средства есть.

S>Например, здесь

Еще один дракон?

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


http://www.shevkin.ru/?action=Page&ID=232


Там в середине статьи про метод координат есть кое-что

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

FR>Еще один дракон?

Это конечно, далеко не UML. Однако же это нечто совершенно иное, по крайней мере
мне ранее подобные вещи не всречались.

Кстати, а что Вы думаете о Драконе?
По моему, автор просто опоздал с ним этак лет на 15-20. Есть несколько очень разумных идей, но все это в среде процедурного программирования.

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

FR>Еще один дракон?
Вобще-то, это было всего лишь предложение для "Дарней", на его фразу:
"Я бы хотел иметь возможность представить возможные пути исполнения проги в виде графа — это сильно упростило бы жизнь в некоторых случаях."
По-моему, на этом сайте есть примерно то, что ему хотелось.

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

S>Кстати, а что Вы думаете о Драконе?
S>По моему, автор просто опоздал с ним этак лет на 15-20. Есть несколько очень разумных идей, но все это в среде процедурного программирования.

Я думаю дракон может быть хорош как средство программирования для непрограммистов и
как альтернатива UML.
Для программистов он бесполезен.

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

FR>Я думаю дракон может быть хорош как средство программирования для непрограммистов и
FR>как альтернатива UML.
FR>Для программистов он бесполезен.

Я думаю, программирование за это время ушло достаточно далеко от процедурного стиля. ООП, событийное программирование, и т.д. сильно уменьшают область применимости процедурных техник. Тем не менее, мне например, довольно часто приходится программировать более-менее сложную логику, и чтобы не запутаться в ней, обычно рисую схемы – алгоритмов, состояний и т.д. И здесь некоторые правила, которые я нашел у Паронджанова, вполне применимы.
Это положительное. Отрицательное и спорное у него тоже имеется, но это наверное уже другая история…

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

AVK>Здравствуйте, Дарней, Вы писали:

Д>>а как их можно взвесить?

AVK>Например измерив момент импульса.

Все физические величины, которые имеют в своем названии слово "момент" относятся к вращательному движению, которое в свою очередь никак не связано микрочастицами.

А насчет массы фотонов — можно посчитать. Энергия фотона вычисляется по формуле E=hν, где h — постоянная Планка и ν (греческая буква ню) — частота фотонов). С другой стороны энергия равна E=mc^2. Масса значит выражается как m=hν/c^2

VD>>Ага. Истенная 3D визуализация процесса можификации переменной.
Д>Зря ты смеешься. Я бы хотел иметь возможность представить возможные пути исполнения проги в виде графа — это сильно упростило бы жизнь в некоторых случаях.

То есть, понять, что от чего зависит. То есть, сделать шаг в сторону static single assignment form.

То есть, получить представление программы в виде, более напоминающим функциональный.

Ура, товарищи!

Д>>Зря ты смеешься. Я бы хотел иметь возможность представить возможные пути исполнения проги в виде графа — это сильно упростило бы жизнь в некоторых случаях.
IT>Это упростило бы жизнь в самых простейших случаях, которые настолько просты, что на практике интересны исключительно в качестве иллюстрации существования визуального программирования.

В общем, соглашусь.

Я прошлым летом понастроил графов программ. Низкоуровневых, правда, но всё же. Да в декабре добавил графы схем, полученных из VHDL (думал, поможет, и помогло, но на очень простых примерах, зато доказал правильность работы программы на них).

Общее впечатление: чтобы разобраться в графе, надо вложить в улучшение его понимаемости человеком столько, что проще просто читать текст программы с добавленными компилятором аннотациями.

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

S>Я думаю, программирование за это время ушло достаточно далеко от процедурного стиля. ООП, событийное программирование, и т.д. сильно уменьшают область применимости процедурных техник. Тем не менее, мне например, довольно часто приходится программировать более-менее сложную логику, и чтобы не запутаться в ней, обычно рисую схемы – алгоритмов, состояний и т.д.

Я тоже рисую, но мои рисунки гораздо более высокоуровневые чем дракон

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

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

OT>>Встречный вопрос: сколько чертежей нужно, чтобы полностью раскрыть проект, реализованый в 3х-мерном виде в том же архикаде?

Д>а вы случаем не еврей?
Д>в любом случае — не думаю, что больше (или хотя бы сравнимо по объему), чем аналогичное по информативности описание плоским текстом

Уверяю тебе, что человеку оперировать с текстовой информацией намного легче, чем с визуально-графической. Картинку, которая оторажает простую схему, к примеру, может легче окинуть глазами, чем текстовое описание этой схемы, но так будет только на игрушечных примерах. В реальной же жизни твоя схема выродится в адское переплетение линий, и в этой паутине разобраться будет практически невозможно. Текст же имеет то громадное преимущество перед графикой, что позволяет по мере необходимости скрывать незначительные детали, повторно использовать описания, а ассоциативные процессы потом помогут человеку развернуть это описание в полную картину. Так устроен человеческий мозг — представить сразу огромное множество мелких деталей намного сложнее, чем произвести логический вывод нужных деталей.
Поэтому языки программирования, как формализованные языки общения человека с машиной, гораздо более прогрессивны, чем блок-схемы, отображающие алгоритм и прочая графика. Ты просто наверное ни разу не пытался открыть какую-нибудь 3d модель с 10k полигонов в 3ds max.

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

G>Все физические величины, которые имеют в своем названии слово "момент" относятся к вращательному движению, которое в свою очередь никак не связано микрочастицами.

Описка. Имелся в виду просто импульс.

G>А насчет массы фотонов — можно посчитать.

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

P.S. А чем ты, интересно, руководствовался, отвечая на сообщение более чем трехлетней давности?