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

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

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

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

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

ОК, только вот сравни число символов/переменных в средней формуле со средним числом переменных и других служебных слов в программах. Плюс математические книжки выходит читаются не как обычные (одномерно), а как-то совершенно иначе.
Кстати, на уровне догадки, человеческая мысль она более-менее последовательна, по меньшей мере отслеживать сразу несколько направлений развития мысли довольно сложно (по меньшей мере мне). Мат. формула есть лишь удобная запись какого-нибудь одного (порой довольно сложного) факта, но доказательства и прочие описания в математической литературе состоят из последовательной череды фактов, так же как мысль развивается от одного заключения к другому.

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

D>Это всяческие визуальные редакторы xslt, для него есть и diff и merge, xml всё таки, рефакторинг; мышкой его набирать часто быстре,

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

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

К>ОК, только вот сравни число символов/переменных в средней формуле со средним числом переменных и других служебных слов в программах.
Дык если любую формулу записанную в структурном виде переписать в линейный вид (одной строкой), то по любому будет больше символов, тк нужно будет расставлять скобки и запятые. Например в структурном виде
n
----
\
\
/
/
----
i=0
у нас 5 условных символов. Если записать линейно: sum(i,0,n) будет 8 условных символов: "sum" "," "," "(" ")" "i" "0" "n"

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

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

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

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

К>>ОК, только вот сравни число символов/переменных в средней формуле со средним числом переменных и других служебных слов в программах.
M>Дык если любую формулу записанную в структурном виде переписать в линейный вид (одной строкой), то по любому будет больше символов, тк нужно будет расставлять скобки и запятые. Например в структурном виде
M> n
M>----
M>\
M> \
M> /
M>/
M>----
M>i=0
M>у нас 5 условных символов. Если записать линейно: sum(i,0,n) будет 8 условных символов: "sum" "," "," "(" ")" "i" "0" "n"

Ты очень ошибаешься, т.к. представляешь всё лишь в одной форме, которая тебе привычна, а она далеко не единственная.
К примеру на том же Хаскеле это будет sum i 0 n
(правда непонятен "целиковый" пример, так что, скорее всего в реальности выглядеть будет иначе)

На J это будет выглядеть +/ i.n
(Хотя тут чуть вру т.к. i.n не включает n)
На APL вроде примерно так же (правда про n не сильно в курсе).

К>>Кстати, на уровне догадки, человеческая мысль она более-менее последовательна, по меньшей мере отслеживать сразу несколько направлений развития мысли довольно сложно (по меньшей мере мне). Мат. формула есть лишь удобная запись какого-нибудь одного (порой довольно сложного) факта, но доказательства и прочие описания в математической литературе состоят из последовательной череды фактов, так же как мысль развивается от одного заключения к другому.
M>В книгах они расположены последовательно, потому что по-другому в книге их расположить не получится.
Расположены потому что расположены, очень логично.
M>И если факты между собой не связаны, то мы можем спокойно менять их местами.
А в программах наверное никак нельзя

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

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


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

Можно автора языка тут http://forum.oberoncore.ru/viewtopic.php?f=28&t=493 попробовать поймать.
Вообще дракон интересная вещь, и по моему намнго удобнее чем UML для алгоритмизации и работе на бумаге.
Но как полноценный язык программирования слабоват и многословен, зато конечно читабелен и кривая обучения
очень пологая
Да про космические корабли, все-таки как я понял (по обсуждению в ссылке выше) там нет объемного
кодирования, зато необходима надежность и легкое использование не программистами, это дракон
вполне обеспечивает.

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

Думаю, вопрос выбора между графическим и текстовым представлением не имеет одного абсолютно универсального решения. И разница между этими представлениями куда глубже, нежели наличие тулов для диффа или врозможности таскать мышкой.
Основное отличие текстового и графического представлений состоит в том, каким обрназом человек их воспринимает. Текстовое представление читается последовательно, строчка за строчкой. А графическое — одним охватом, параллельно. Именно это наличие последовательности, текущего положения, и является кардинальным отличием одного от другого, и именно из этого проистекают их достоинства и недостатки.
Исходя из этого, легко понять, где будет выгодно текстовое представление, а где графическое. Первое предпочтительне, когда нужна информация о том, в какой последовательности нужно воспринимать информацию, когда содержащаяся логика слоржна и требует внимательного отслеживания логических цепочек. Ну то есть императивные и функциональные универсальные языки — это именно оно.
В противоположность, графическое представление удобнее, когда нам важно отразить структуру, когда важно понимание этой структуры в целом и связей внутри нее. Отсюда такие вещи, как, скажем, deployment diagramm в студии, ER-диаграммы сотоварищи, предпочтительнее в графическом виде.
Важно — не существует абсолютной границы, разумеется, а есть непрерывный спектр. Скажем, тот же язык запросов к БД в чем то удобнее в текстовом виде, в чем то в графическом, но текстовое все же обычно предпочтительнее просто ввиду того, что текстовые тулзы намного качественее.
Теперь что касается универсальных языков программирования. Суть задачи такова, что, все таки, текстовое представление более предпочтительно. И, если уж выбирать что то одно, такой язык, если это не игрушка и не обучающая программа, должен быть текстовым.
Другое дело что более оптимальным является смешанное представление. Понятно, что, если взять тот же шарп или джаву, то там, по сути, два довольно таки изолированных куска имеем: декларацию сущностей дизайна и наполнение методов. И первое скорее всего в графическом виде все таки удобнее. Первые шажки в этом направлении это, наверное, Смоллток. В студии есть двунаправленная диаграмма классов. Однако два разных редактора для одного и того же — это не совсем то, что способствует продуктивности. Редактор должен быть один. Как это в итоге будет выглядеть — отдельный большой вопрос. Что то такое есть в DevExpress CodeRush. Очень интересна концепция, которую мне Кирилл Осенков показывал, но он, к сожалению, не хочет пока что показывать это публично, так что я не буду об этом распространяться.

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

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

Примерно так же как в DirectShow сейчас. Посмотри любой редактор графа для DirectShow.

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

G>У меня щас программулина — так там 1.5 млн строк, и я даже представить боюсь, как бы она выглядела, будь она вот в таком виде напедалина.

А у тебя вся программулина в один метод вписана, что-ли? Декомпозиция есть и там и там. Если учесть, что рекомендуется каждый метод делать не более 1-2-х экранов монитора, то и схемы будут соответствующие.

Твоя программулина отобразится на иерархию блоков, всего-то.

http://www.gameroo.nl/games/light-bot — кубикоподобный язык для программирования робота