Здравствуйте, Mr.Cat, Вы писали:
MC>Первично ведь не желание лапать картинки, а стремление к тому, чтобы код читался как спецификация — а спецификация не всегда выражена красивыми рисунками. Часто это именно текст, возможно — математические выкладки т.п. Если в каких-то задачах удобнее рисовать картинки — велком. Этого и сейчас никто не запрещает (обратим внимание хотя бы на дизайнеры форм или, например, WWF) — рисуй себе. Но не надо всех чесать под одну гребенку.
Тут все хуже чем кажется.
Проблема с картинками в том что они работают пока задача маленькая.
Но как только задача становится большой тушите свет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, dotidot, Вы писали:
D>Здравствуйте, LaptevVV, Вы писали: LVV>>Блин!!!!!!!!!!!!!!!! LVV>>Как представлена прога внутри — человеку пофиг! LVV>>А IDE делает из внутренней МОДЕЛИ ПРЕДСТАВЛЕНИЕ ДЛЯ ЧЕЛОВЕКА! LVV>>Чего тут непонятного-то? D>обоже как же вас достали студенты. D>А современная программа — это ИМХО не ast, это сложная совокупность разрозненных модулей, сцепленных через опубликованные интерфейсы. А модули могут быть разными, например на результате обработки ЯПа. Вот дотнетовская assembly это ast? D>Можно еще и сложнее завернуть, рассмотрев, например, веб интерфейс к системе оркестрации бизнес процессов. там вообще слабо понятно, что есть программа, а что есть конфиг.
"n все понятно. В ББ так Франц специальное представление придумал. SDE называется. Я АСТ написал просто потому, что про него все знают...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, avishnyakov, Вы писали:
A>Я нахожу это довольно удобным и хотел бы поюзать. A>По поводу крчения головой — ну два моника и все будет ок.
A>То, что на видео — по факту адекватная навигация между горкой файлов в открытых табах студии с отличным и настраиваемым таргетингом контента
A>Из плюсов лично для меня — я не буду терять время на переключение по табам между файлами проекта или же клацать по ф-циями по F12. A>Я всегда можно иметь на одном экране стек вызовов горки ф-ций или иную логику/алгоритм/кусок алгоритма из N ф-ций из M классов — это очень удобно.
A>Прозрачно смотрится логика, все что нужно всегда под рукой, быстро вносятся изменения в нужные места.
A>Тру
Вот почему я не могу перейти с nedit на что-то типа Визуал-студии.
Nedit позволяет разложить на рабочем столе несколько файлов (одновременно видимых).
А студия не позволяет.
И мне в студии "неудобно".
Здравствуйте, любой, Вы писали:
Л>Здравствуйте, DrDred, Вы писали:
DD>>Вопрос собственно говоря следующий — имеет ли подобная технология право на жизнь, или это просто никому не нужное украшательство, за которым приятно наблюдать, но не работать?
Л>Посмотрел пол ролика. Направление мысли правильное. Но насколько удачна данная реализация не могу сказать. Л>Меня файло-тексто-ориентированность исходников программы достаёт давно. Исполняемый код — это граф. Движение данных в программе — тоже граф. Структура наследования и агрегирования классов — граф. И безусловно IDE должно давать возможность виветь эти графы с разной степенью детализации, предоставлять исчерпывающие возможности навигации во всех измерениях, редактировать код на месте, трансформировать эти графы. Что-то из этого есть в UML. Но на практике проще написать программу без него.
Графическое представление хорошо воспринимается, когда изображаемых обьектов не больше 11
Инженерная психология, понимаешь.
Здравствуйте, alpha21264, Вы писали:
A>Графическое представление хорошо воспринимается, когда изображаемых обьектов не больше 11 A>Инженерная психология, понимаешь.
А неграфическое при любом числе объектов воспринимается хуже. Но никто и не обязывает воспринимать бОльшее число объектов. Речь идёт о том, чтобы сделать максимально удобную навигацию по программе. Скажем, находясь в каком-то методе нужно иметь перед глазами хотя бы все методы, из которых он вызывается, с возможностью перехода к ним за один клик. Ну и которые он вызывает тоже. Код метода тоже состоит из вложенных блоков, которые образуют не линейную, а древовидную или даже более сложную (при использовании переходов) структуру. И нужна навигация не по тексту, а по этим блокам. Например, если я смотрю одну из ветвей оператора switch, мне важно также видеть, что будет после всех case'ов. А в обычном текстовом редакторе далее по тексту может оказаться несколько экранов кода, соответствующего остальным case'ам.
Здравствуйте, WolfHound, Вы писали:
LVV>>Программа — это не текст!, а АСТ! Дык пусть его и делает редактор, а не компилятор! WH>Осталось выяснить почему ВСЕ попытки пойти этим путем с треском провалились...
Как это все? А как же среды для VHDL?
WH>А тоже время IDE которые в своей основе держат текст прекрасно живут.
Своей унаследованной традиционностью. Адекватные возможности среднего железа для обсуждаемых редакторов появились дай бог лет 10 назад, а языками мы пользуемся очень древними. Тот же C# тому пример: синтаксис С++/Java, приправленный сахарком, плюс небольшие заимствования из древних ф-ых языков.
Для обсуждаемых IDE нужен декларативный язык, а не императивный или функциональный. Например, реактивное программирование движется в нужном направлении, и будет там раньше всех.
Здравствуйте, alpha21264, Вы писали:
A>Nedit позволяет разложить на рабочем столе несколько файлов (одновременно видимых). A>А студия не позволяет. A>И мне в студии "неудобно".
В 2010-й наконец-то сделали поддержку мультимонитора.
Например, если я смотрю одну из ветвей оператора switch, мне важно также видеть, что будет после всех case'ов. А в обычном текстовом редакторе далее по тексту может оказаться несколько экранов кода, соответствующего остальным case'ам.
Тут закладки помогают. Для других случаев иногда полезно code definition window.
Здравствуйте, WolfHound, Вы писали:
WH>Проблема с картинками в том что они работают пока задача маленькая. WH>Но как только задача становится большой тушите свет.
Серьезно? А сотни миллионов транзисторов на кристалле — это маленькая задача?
Обычная модульность и компонентность все разруливает. С "картинками" удобно невероятно, поработай интереса ради в редакторах электронных схем. Описываешь модуль, его интерфейс, набиваешь его составные части из других таких же модулей и примитивов и т.д. Целкнул дважды по "квадратику"-модулю, и открыл его кишки-устройство, и так рекурсивно до самого нижнего уровня.
Я уже молчу о том, что программисты в массе своей и понятия не имеют, как должны быть организованы и как удобно на самом деле можно пользоваться библиотечными компонентами, ибо пока в программировании в плане библиотек ничего не менялось с 60-х годов.
Здравствуйте, DrDred, Вы писали:
DD>Доброго времени суток,
DD>натнулся тут на любопытный ролик здесь
Первые пару секунд было прикольно, потом я начал фантазировать на тему, что работаю в такой IDE и мне стало не по себе. Во-первых, зачастую приходится работать с длинными достаточно широкими методами, который будут съедать большую часть места. Как это будет выглядеть непонятно. Во-вторых, часто мне надо посмотреть метод только для справки, чтобы освежить информацию. После этого закрыть если не навсегда, то надолго. В ролике на экране показано много мелких простых методов, а чего на них постоянно глазеть то?
Здравствуйте, vdimas, Вы писали:
V>Обычная модульность и компонентность все разруливает. С "картинками" удобно невероятно, поработай интереса ради в редакторах электронных схем. Описываешь модуль, его интерфейс, набиваешь его составные части из других таких же модулей и примитивов и т.д. Целкнул дважды по "квадратику"-модулю, и открыл его кишки-устройство, и так рекурсивно до самого нижнего уровня.
А насколько удобно и просто "распухнуть" там изначальный микромодуль до монстра сложной формы?
V>Я уже молчу о том, что программисты в массе своей и понятия не имеют, как должны быть организованы и как удобно на самом деле можно пользоваться библиотечными компонентами
Ибо далеко не под все требуемые задачи есть эти самые "библиотечные компоненты".
Здравствуйте, Nuzhny, Вы писали:
N>Тут закладки помогают. Для других случаев иногда полезно code definition window.
В VS много есть всяких рюшечек, которые проблему навигации облегчают. Блоки с кодом можно вручную схлопываь/расхлопывать с помощью -/+ на панели слева от текста. Но это всё требует лишних прицеливаний мышью, кликов. Пока окна с текстовыми файлами составляют основу интерфейса, он будет очень далёк от идеала.
Здравствуйте, CreatorCray, Вы писали:
V>>Обычная модульность и компонентность все разруливает. С "картинками" удобно невероятно, поработай интереса ради в редакторах электронных схем. Описываешь модуль, его интерфейс, набиваешь его составные части из других таких же модулей и примитивов и т.д. Целкнул дважды по "квадратику"-модулю, и открыл его кишки-устройство, и так рекурсивно до самого нижнего уровня. CC>А насколько удобно и просто "распухнуть" там изначальный микромодуль до монстра сложной формы?
Зачем? Если схема получается сложной, выделяй ее части в модули (с автоматическим формированием внешнего интерфейса), мышкой за секунды делается. В коде это зовется "рефакторингом", а в визуальной среде такой рефакторинг происходит непрерывно.
Тут еще такой момент, что модули — это "виртуальные" сущности, т.е. они не добавляют той самой коссвенности конечному решению, как добавляют ее классы, которые участвуют в некоем ОО-дизайне по ссылке. Я тебе скажу, что в тексте, даже при поддержке IDE, управлять такой глубиной вложенности (аналогично — глубиной иерархии ООП) просто невозможно. Более того, глубокие ООП-иерархии — это признанный источник ненадежности кода, в то время как при проектировании железа — ровно наоборот. Потому как в кач-ве инструмента декомпозиции выступает не наследование, а агрегирование+реализация стандартных интерфейсов, а эта техника чем "глубже", тем проще и надежнее на каждом отдельно взятом уровне.
Улыбает то, что некоторые пытаются эти древние подходы к дизайну сложных систем преподнести как "новую" манеру проектирования в ПО, в общем, весело. Я еще лет 15 назад говорил, что программистам полезно поучиться у электронщиков, особенно в плане практик относительно надежности решений.
V>>Я уже молчу о том, что программисты в массе своей и понятия не имеют, как должны быть организованы и как удобно на самом деле можно пользоваться библиотечными компонентами CC>Ибо далеко не под все требуемые задачи есть эти самые "библиотечные компоненты".
Даже о тех, что есть, программист должен или догадаться, или искать в необъятной документации, т.к. библиотеки не организованы в базу знаний с навигацией. Я даже не всегда навскидку скажу, в какой ассембли лежит тот или иной специфичный класс. И, если честно, и не хотел бы знать до момента деплоймента.
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, БлэкБокс как раз не блести... Это Микрософт на каждом углу пиарится... А те ребята молча делают свое дело. И один из них — Шиперски — в Микрософте как раз работает. Потому и подвижки у них в среде C#, я так понимаю, довольно серьезные пошли.
Не знаю, о каких подвижках речь, но твой Шиперски точно к ним отношения не имеет. Я многих из текущих идеологов VB&C# IDE знаю лично, и никто из них про Оберон ни разу даже не упоминал. Таким образом, твоя конспирология мимо цели.
LVV>>>3. Для обучения Компонентный паскаль НАМНОГО лучше С++. AVK>>О да. LVV>По мне, чем на старом-старом ТурбоПаскале учить, так гораздо лучше учить в школе на Компонентном Паскале в БлэкБоксе.
А еще лучше использовать для этого Java.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Здравствуйте, vdimas, Вы писали:
V>Улыбает то, что некоторые пытаются эти древние подходы к дизайну сложных систем преподнести как "новую" манеру проектирования в ПО
ИМХО и этот подход провалится, как и все до него.
V>Я еще лет 15 назад говорил, что программистам полезно поучиться у электронщиков, особенно в плане практик относительно надежности решений. Какой смысл?
Я со своей колокольни наблюдаю следующее: электроника всё больше переходит в стадию: а вместо вот этой всей мегасхемы мы воткнём микроконтроллер с необходимым ему минимумом и напишем к нему прошивку, потому как в разы проще получится. Даже тупо фонарик с разными режимами работы на контроллере делают, ибо меньше по размерам, быстрее в разработке и проще в реализации.
Так как прикажешь применять опыт практик разработки электроники к разработке софта если объём логики в электронике стараются как можно более уменьшить, перекладывая имплементацию этой логики с электроники на софт? Мне лично это говорит что большие системы делать методом электронщиков — очень геморно, несмотря на мегатулы.
Разумеется я могу что то не так со своей колокольни видеть. Ну на то она и колокольня. Поправь если что.
Здравствуйте, CreatorCray, Вы писали:
CC>Я со своей колокольни наблюдаю следующее: электроника всё больше переходит в стадию: а вместо вот этой всей мегасхемы мы воткнём микроконтроллер с необходимым ему минимумом и напишем к нему прошивку, потому как в разы проще получится. Даже тупо фонарик с разными режимами работы на контроллере делают, ибо меньше по размерам, быстрее в разработке и проще в реализации.
А контроллер боженька нам материализует? В этом сегменте тоже конкуренция ого.
CC>Так как прикажешь применять опыт практик разработки электроники к разработке софта если объём логики в электронике стараются как можно более уменьшить, перекладывая имплементацию этой логики с электроники на софт?
Пока что развитие процессоров говорит ровно об обратном, все больше делается в железе того, что раньше делал софт.
CC>Мне лично это говорит что большие системы делать методом электронщиков — очень геморно, несмотря на мегатулы.
Из ложной предпосылки ложный вывод. И ты не заметил, что плане аппаратуры я упор делал на надежность.
Здравствуйте, alpha21264, Вы писали:
A>Вот почему я не могу перейти с nedit на что-то типа Визуал-студии. A>Nedit позволяет разложить на рабочем столе несколько файлов (одновременно видимых). A>А студия не позволяет. A>И мне в студии "неудобно".
Просто у тебя недостаточно опыта в ее применении. Начнем с того, что в студии можно включить поддержку MDI-интерфейса и раскладывать хоть все файлы по окну.
Плюс в студии можно разделять окна, что и в не MDI-интерфейсе позволяет отображать более одного файла за раз.
А по уму в студии нужно работать с использованием навигации по коду. Тогда и много окон не понадобится. Все равно за раз можно только с одним работать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, alpha21264, Вы писали:
A>>Nedit позволяет разложить на рабочем столе несколько файлов (одновременно видимых). A>>А студия не позволяет. A>>И мне в студии "неудобно".
N>В 2010-й наконец-то сделали поддержку мультимонитора.
Чего? Студия не может растянуть окно на два монитора?!!!
Какой смысл?
