Написать C++ графически, как нуля?
Я рассматриваю возможность разработки приложения, которое позволило бы людям разрабатывать код на C++ графически. Я был поражен, когда обнаружил Scratch (см. Сайт и обучающие видео).
Я считаю, что большая часть C++ может быть представлена графически, за исключением инструкций препроцессора и, возможно, указателей на функции.
Какие функции C++, на ваш взгляд, могут (или не быть) представлены графическими элементами? Каковы будут плюсы и минусы такого приложения? Насколько проще было бы, чем "простой" C++?
ЗАПИСЬ и БОЛЬШЕ:
Плюсы:
- интуитивный
- просто для небольших приложений
- помогает избежать опечаток
Минусы:
- может стать нечитаемым для больших (средних?) приложений
- ручное кодирование быстрее для опытных программистов
- C++ слишком сложный язык для такого подхода
Учитывая, что у нас - на моей работе - уже есть немного кода на C++, я не ищу совершенно новый способ программирования. Я рассматриваю альтернативный способ программирования, полностью совместимый с устаревшим кодом. Какой-то "вирусный язык", который люди будут использовать для нового кода и, будем надеяться, в конечном итоге также будут использовать для замены существующего кода (где это может быть полезно).
Как вы относитесь к этому вирусному подходу?
Когда дело доходит до ручного и графического программирования, я склонен согласиться с вашими ответами. Вот почему в идеале я найду способ, позволяющий пользователю всегда выбирать между набором текста и графическим программированием. Строковый синтаксический анализатор (+ частичный интерпретатор) может преобразовывать типизированный код в графический дизайн. Это возможно Давайте все скрестим пальцы.
Есть ли какие-то предостережения относительно предоставления возможностей как для ввода текста, так и для графического программирования, о которых мне следует подумать и тщательно проанализировать?
Я уже работал над шаблонными классами (и в более общем смысле на уровне типов C++) и их графическим представлением. Смотрите там пример графического представления шаблонных классов. Коробки представляют классы или шаблоны классов. Первый верхний узел - это сам класс, следующие (если они есть) - инструкции typedef внутри класса. Нижние узлы являются аргументами шаблона. Конечно, края соединяют классы с аргументами шаблона для создания экземпляров. У меня уже есть прототип для работы над такими диаграммами уровня типов.
Если вы чувствуете, что этот способ представления шаблонных классов совершенно неправильный, не стесняйтесь говорить и почему!
11 ответов
Написание кода - самая легкая часть дня разработчиков. Я не думаю, что нам нужна дополнительная помощь с этим. Чтение, понимание, ведение, сравнение, аннотирование, документирование и проверка - вот где - несмотря на огромное количество инструментов и структур - нам все еще не хватает.
Чтобы проанализировать ваши плюсы:
Интуитивно понятный и простой для небольших приложений - замените его на "вводящее в заблуждение". Это выглядит просто, но это не так: пока это просто, VB.NET проще. Когда это усложняется, мешает визуальный дизайн.
Помогите избежать опечаток - вот для чего нужен хороший стиль, последовательность и, что не менее важно, интеллигентность. Вещи, которые вам нужны в любом случае, когда все становится не так просто.
Неправильный уровень
Вы думаете на неправильном уровне: операторы C++ не являются повторно используемыми, надежными компонентами, они больше похожи на большую сумку с шестеренками, которые должны быть правильно собраны. C++ с его сложностью и исключениями (для правил) даже не подходит.
Если вы хотите упростить задачу, вам нужны повторно используемые компоненты на гораздо более высоком уровне. Даже если они у вас есть, их не просто соединить. Несмотря на годы борьбы и множество попыток во многих средах, это иногда работает и часто терпит неудачу.
Вирусный - вы правы IMO в отношении этого требования: разрешить постепенное принятие. Это тесно связано с плавным переключением между исходным кодом и визуальным представлением, что, в свою очередь, означает, что вы должны иметь возможность генерировать визуальное представление из модифицированного исходного кода.
Поддержка IDE - вот где большинство языковых подходов сбивается с пути. Современная IDE - это больше, чем просто текстовый редактор и компилятор. Как насчет отладки вашего графика - с точками останова, проверкой данных и т. Д.? Будут ли профилировщики, детекторы утечки и т.д. выделять узлы на вашем графике? Даст ли мне контроль над исходным кодом визуальное отличие вчерашнего графика от сегодняшнего?
Может быть, вы что-то делаете, несмотря на все мои "нет": лучший способ визуализации кода, способ установки на него различных фильтров, чтобы я мог видеть именно то, что мне нужно.
Как бы мне ни нравился Scratch, опытный программист по-прежнему гораздо быстрее пишет код с помощью текстового редактора, чем перетаскивает блоки. Это было доказано снова и снова с любым количеством графических сред программирования.
Ранние версии C++ изначально были написаны так, чтобы они компилировались в C, затем C был скомпилирован как обычно.
То, что вы описываете, похоже на то, что это графический язык, скомпилированный в C++, который затем будет скомпилирован как обычно.
Так что на самом деле вы не создаете графический C++, вы создаете новый язык, который оказывается графическим. В этом нет ничего плохого, но не позволяйте C++ ограничивать то, что вы делаете, потому что в конечном итоге вы можете захотеть скомпилировать графический язык прямо в машинный код или даже в что-то вроде CIL, Java ByteCode или чего-то еще, что поражает ваше воображение.
Другими графическими языками, которые вы, возможно, захотите проверить, являются LabVIEW и, в более общем смысле, категория языков визуального программирования.
Удачи в ваших усилиях.
Сложность нетривиальной программы обычно слишком высока, чтобы ее можно было представить графическими символами, которые имеют низкую информативность. Если ваш подход не будет заметно отличаться в некотором роде, я скептически отношусь к тому, что это будет иметь ценность на основе прошлых усилий.
Так что, собственно говоря, он будет полезен только для учебных целей и очень простых программ. Но это все равно было бы отличным целевым рынком для такого продукта. иногда людям трудно понять основы, и визуальная модель может быть как раз для того, чтобы помочь вещам щелкнуть.
Интересная идея. Я сомневаюсь, что использовал бы это все же. Я предпочитаю кодировать в текстовом редакторе, даже не в IDE, а для сложных задач я предпочитаю блокнот. Большинство действительно опытных программистов, которых я знаю, работают таким образом. Может быть, это потому, что мы выросли в другой среде, но я думаю, что это также из-за того, как мы думаем о программировании. По мере того, как вы приобретаете больше опыта, вы начинаете видеть код в своей голове более четко, чем любой инструмент с графическим интерфейсом.
Что касается вашего вопроса, я бы назвал шаблоны как одну из наиболее сложных / интересных вещей, чтобы попытаться хорошо представить. Они вездесущи и несут информацию, к которой у вас не будет доступа при разработке инструмента. Полезное донесение до пользователя должно стать интересной задачей.
Я предпочитаю горячие клавиши вместо графических меню и кнопок.
И я думаю, что то же самое произойдет с графическим инструментом разработки. Многие люди предпочтут ручную кодировку.
Но визуализатор исходного кода - должно быть хорошо.
Мне нравится идея, но я подозреваю, что наступает момент, когда вещи становятся слишком сложными, чтобы представлять их графически.
Однако, учитывая недавний опыт работы; было бы полезно дать такой графический интерфейс неопытному человеку, чтобы использовать его для создания основных программ перетаскивания, оставляя меня свободным заниматься некоторым "правильным" программированием;-) Если это может сделать работу Позволить кому-то неопытному создать что-то функциональное, это может быть очень хорошо (даже если логика программирования избегает его)
В такой системе наступает момент, когда становится проще определить, что вы хотите делать, используя буквальный код C++, а не мешать пользовательскому интерфейсу; это может расстроить сессионного программиста, который знает точный код, который должен быть написан, но при этом ограничивается только графическим интерфейсом разработчика. Я специально думаю о более распространенном приложении, таком как редакторы / дизайнеры HTML, в которых они позволяют новичкам создавать свои веб-сайты, вообще не зная HTML.
Было бы интересно посмотреть, как такая система будет обрабатывать динамическое распределение памяти и различные состояния программы с течением времени; Я подозреваю, что есть некоторые очень базовые концепции программирования, которые может быть трудно представить графически.. Полиморфизм..? Виртуальные классы, LinkList, Стеки / Круговые очереди. На мгновение я удивляюсь, как бы вы успешно объяснили алгоритм сжатия изображений (например, jpg) без помощи гигантского экрана.
Мне также интересно, перейдет ли такая система на столь низкий уровень, и будете ли вы иметь дело с абстрактными понятиями, и компилятор разработает лучший способ что-то сделать.
Как вы думаете, какие функции C++ могут быть представлены [...] графическими элементами?
Объектно-ориентированный дизайн. Отсюда классы, наследование, полиморфизм, изменчивость, константность и т. Д. И шаблоны.
Каковы будут плюсы и минусы такого приложения?
Новичкам может быть легче начать писать программы. Для опытных это может быть избавление от скучных частей программирования.
Подумайте о любом другом генераторе кода. Они создают основу для вас, чтобы написать более вовлеченные части. Они также приводят к раздутому коду (подумайте о любом WYSIWYG HTML-редакторе).
Самая большая проблема, на мой взгляд, заключается в том, что любой такой интерфейс обязательно мешает воображению пользователя.
Насколько проще было бы, чем "простой" C++?
Это может быть реальная боль, когда вы перебираете грузы ошибок, что типично для генераторов кода.
Кроме того, поскольку генерируется много кода, вы понятия не имеете, что происходит - отладка становится сложной.
Кроме того, для опытных пользователей может возникнуть некоторое раздражение, когда они обнаружат, что сгенерированный код не соответствует их предпочтительному стилю кодирования.
Я работал над новой парадигмой разработки программного обеспечения на основе моделей, названной ABSE ( http://www.abse.info/), которая поддерживает программирование для конечных пользователей: это система на основе шаблонов, которая может быть дополнена кодом преобразования. У меня также есть IDE (с именем AtomWeaver), реализующий ABSE, который сейчас находится на пре-альфа-стадии.
С AtomWeaver, будучи экспертом / архитектором, вы создаете свои шаблоны знаний, а затем разработчики (или конечные пользователи, если вы упрощаете свои метамодели) могут просто "собирать" системы, создавая блоки, а затем заполнять параметры шаблона в форме. в стиле редакторов.
В конце, нажатие кнопки "Создать" создаст окончательную систему в соответствии с указаниями архитектора / эксперта.
Я удивлен, что вы думаете, что указатели на функции были бы особой проблемой. Как насчет указателей?
Язык программирования может быть представлен иерархией узлов - это именно то, во что это превращает компилятор. Очень странно, что пользовательский интерфейс для редактирования программ по-прежнему представляет собой последовательность символов, которые анализируются, потому что степени свободы в редакторе намного больше, чем доступный набор разрешенных вариантов. Но intellisense помогает значительно уменьшить эту проблему.
C++ был бы странным выбором для такой системы.
Я думаю, что основная проблема IDE такого рода заключается в том, что сгенерированный код легко становится недостижимым.
Это случилось с Дельфи. Это действительно хороший инструмент для разработки каких-либо приложений, однако, когда мы начинаем добавлять сложные отношения между компонентами, начинаем добавлять шаблоны проектирования и т. Д., Код увеличивается до недостижимого размера.
Я полагаю, что это также потому, что графические инструменты не применяют концепцию MVC (или, если они это делают, это только в том смысле, который понимает IDE).
Это может быть очень полезно для прототипов и очень маленьких приложений, которые не имеют тенденцию расти, в противном случае это может стать путаницей для разработчиков