Комментарии 54
Интересно. Только вот кажется мне, что образ мышления для программирования подобным образом придется поменять. Условные переходы, циклы и прочее, более естественны для восприятия и понимания. Понятное дело что это только вариация на тему, но думаю стоит ввести дополнительные абстракции для данного случая, потому что сложные программы читать в таком виде будет крайне тяжело, если вообще возможно.
Хотя в тоже время визуализация положительно скажется на совместных обсуждениях кода с коллегами и при парном программировании.
Хотя в тоже время визуализация положительно скажется на совместных обсуждениях кода с коллегами и при парном программировании.
> Условные переходы, циклы и прочее, более естественны для восприятия и понимания.
Вы так говорите, потому что вы так учились программировать) А схематические таблицы — это и есть более высокий ровень абстракции.
При записи на языке программирования, вам приходится думать по одному символу за раз:
«i-n-t e-f-f-e-c-t-i-v-e-n-e-s-s = p-o-w-e-r * (s-u-r-p-r-i-s-e? 3: 2);».
А при записи в схематической таблице вам нужно создать колонку, добавить в нее операцию * и перетащить мышкой соответствующие переменные на место аргументов этой операции.
Джонатан пытается сказать нам, что история программирования еще не закончена и можно найти лучшие способы записи программной логики, чем набирание кода по одному символу (autocompletion не в счет). И я с ним согласен.
Вы так говорите, потому что вы так учились программировать) А схематические таблицы — это и есть более высокий ровень абстракции.
При записи на языке программирования, вам приходится думать по одному символу за раз:
«i-n-t e-f-f-e-c-t-i-v-e-n-e-s-s = p-o-w-e-r * (s-u-r-p-r-i-s-e? 3: 2);».
А при записи в схематической таблице вам нужно создать колонку, добавить в нее операцию * и перетащить мышкой соответствующие переменные на место аргументов этой операции.
Джонатан пытается сказать нам, что история программирования еще не закончена и можно найти лучшие способы записи программной логики, чем набирание кода по одному символу (autocompletion не в счет). И я с ним согласен.
С другой стороны, чтобы понять код, я читаю его в одной последовательности — сверху вниз слева направо. Пока я пытался понять, что же делает таблица, глаза бегали во все возможные стороны. А если она разрастется до, скажем, 20 условий и переменных, то придется крутить головой еще сильнее чтобы вспомнить, какая строка \ столбец за что отвечает.
Концепция сетки чем-то напоминает мне мой первый инструмент программирования — The Games Factory. Так правда было слегка наоборот — по вертикали условия, а по горизонтали объекты, над которыми можно проводить действия. Вообще, достаточно интересный проект.
Для нелюбителей платить деньги есть более молодой бесплатный аналог, созданный бывшими пользователями TGF — Scirra Construct.
Концепция сетки чем-то напоминает мне мой первый инструмент программирования — The Games Factory. Так правда было слегка наоборот — по вертикали условия, а по горизонтали объекты, над которыми можно проводить действия. Вообще, достаточно интересный проект.
Для нелюбителей платить деньги есть более молодой бесплатный аналог, созданный бывшими пользователями TGF — Scirra Construct.
> можно найти лучшие способы записи программной логики
а можно и худшие
а можно и худшие
> При записи на языке программирования, вам приходится думать по одному символу за раз:
> «i-n-t e-f-f-e-c-t-i-v-e-n-e-s-s = p-o-w-e-r * (s-u-r-p-r-i-s-e? 3: 2);».
Думать по одному символу за раз? Это как?
У меня набором кода обычно руки занимаются, голова о наборе символов не думает.
ИМХО, изучение слепой печати эффективнее любого «мышиного» интерфейса.
Да, кривая обучения гораздо круче. Но это как с карандашом — десять лет учишься им пользоваться, потом всю жизнь используешь не замечая.
> «i-n-t e-f-f-e-c-t-i-v-e-n-e-s-s = p-o-w-e-r * (s-u-r-p-r-i-s-e? 3: 2);».
Думать по одному символу за раз? Это как?
У меня набором кода обычно руки занимаются, голова о наборе символов не думает.
ИМХО, изучение слепой печати эффективнее любого «мышиного» интерфейса.
Да, кривая обучения гораздо круче. Но это как с карандашом — десять лет учишься им пользоваться, потом всю жизнь используешь не замечая.
>При записи на языке программирования, вам приходится думать по одному символу за раз
При чтении человек воспринимает информацию целыми токенами, которые состоят, как минимум, из слов, а обычно — из целых фраз. По буквам текст воспринимает только ребёнок, начинающий учиться читать.
При чтении человек воспринимает информацию целыми токенами, которые состоят, как минимум, из слов, а обычно — из целых фраз. По буквам текст воспринимает только ребёнок, начинающий учиться читать.
Забавно, когда минусуют за общеизвестные истины. Это за их очевидность (но тогда непонятен тезис того, на чей вопрос ответ), или кто-то не знает очевидных вещей?
Впрочем, даже если очевидные вещи кому-то неизвестны, то странно, как можно было пройти мимо заполнившего весь Интернет в своё время мегабояна про малую важность порядка букв в словах: «По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все-рвано ткест чтаитсея без побрелм. Пичрионй эгото ялвятеся то, что мы не чиатем кдаужю бкуву по отдльенотси, а все солво цликеом.»
Впрочем, даже если очевидные вещи кому-то неизвестны, то странно, как можно было пройти мимо заполнившего весь Интернет в своё время мегабояна про малую важность порядка букв в словах: «По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все-рвано ткест чтаитсея без побрелм. Пичрионй эгото ялвятеся то, что мы не чиатем кдаужю бкуву по отдльенотси, а все солво цликеом.»
Перенесите топик в один из тематических блогов.
Тогда топик попадет на главную и его увидит гораздо больше хабралюдей, чего статья, конечно же, достойна.
Тогда топик попадет на главную и его увидит гораздо больше хабралюдей, чего статья, конечно же, достойна.
Напоминает работу компилятора при анализе кода для оптимизации
Ну что значит новое? Нам похожие таблички еще в школе на уроках информатики показывали))
бредовая идея
это все нормально только на ваших академический примерах
так же как и хаскел в универе показывают. для рекурсии и т.п. муры
ну, и плюс запутанные у вас графики
код гораздо понятнее
это все нормально только на ваших академический примерах
так же как и хаскел в универе показывают. для рекурсии и т.п. муры
ну, и плюс запутанные у вас графики
код гораздо понятнее
Наверняка таблицу можно строить автоматически. Ну или код — автоматически. Так что такие идеи только дополнят наш код.
Haskell и прочие языки функционального программирования представляют не только академический интерес.
К примеру, масштабируемость многих сервисов небезызвестного Google достигается как раз использованием элементов функционального программирования.
К примеру, масштабируемость многих сервисов небезызвестного Google достигается как раз использованием элементов функционального программирования.
Спасибо, это интересный подход. Наверняка тут откроются интересные возможности для реализации параллельности — ведь столбцы таблицы в некотором смысле независимы…
Перенесите в блог «Я сумасшедший»)
Похоже, что автор в рамках проекта в очередной раз изобрёл сопоставление по образцу (pattern matching). Или в презентации предполагалось, что аудитория об этом ничего не знает.
Непонятно, почему бы не оставить возможность задавать эту таблицу в коде (текстом), строчка кода — строка таблицы. В качестве альтернативы. Текст — уж очень он универсален.
ну не знаю, стандартная запись кажется удобнее, может, потому что привычнее…
кажется, эти таблички и так строятся на каждому углу в разных IDE.
в той же студии были такие таблички, только как способ анализа кода
в той же студии были такие таблички, только как способ анализа кода
Концепция более или менее ясна, хотя и спорна, но я не нашёл в статье, хотя может из-за своей невнимательности, ссылки на инструмент, которым можно было бы её опробовать. Если такой инструмент есть — укажите на него.
Для скачивания оболочка пока что не доступна. Это исследовательский проект автора.
Я ошибся. Здесь можно скачать исходник вместе с exe-файлом.
похоже на графический редактор для DSL
какая-то помесь носорога с бегемотом — табличек с синтаксическим анализом. Самое главное, непонятно, что тут от собственно табличек? Наличие столбцов — оно, знаете-ли, не показатель. В целом, конечно, занимательно, но ИМХО совершенно нежизнеспособно. Абстрактное такое ощущение, что автор нашел на каком-то этапе такую форму записи, но пока не обкатал и не отбросил ее, как излишне громоздкую.
>>Программирование в таблицах — новая концепция…
Ждём программирования на дивах
Ждём программирования на дивах
Получается что код будет очень сильно расти вширь, потому что любое ветвление/условие добавляет столбец. Я представил такую таблицу для функции WindowProc с ее последовательностью case. Тут не просто никаких wide-мониторов не хватит, а задолбаешься прокручивать код туда/обратно. И не очень понятно, как будет выглядеть IDE для такого кода и как в нем работать.
Идея сама по себе интересная и сырая. На академических примерах, конечно, все красиво, но в более-менее большой программе, боюсь, будет кошмар.
Идея сама по себе интересная и сырая. На академических примерах, конечно, все красиво, но в более-менее большой программе, боюсь, будет кошмар.
А вертикальная последовательность case вас не беспокоит? В любом случае, устройство Windows-приложения не является образцовым примером проектирования. В реальных задачах можно было бы создать отдельную таблицу для каждого case-случая, и передавать им в качестве входных параметров текущее состояние WindowProc. А сгенерированный код, по желанию пользователя, может преобразовать таблицы в case-случаи.
Если создавать отдельную таблицу для каждого случая, то мы получим такую же хрень, как во флеше, когда каждый обработчик в отдельном окошке. Во многих случаях удобно, когда программа вся вместе, а не разорвана по кускам. Та же самая хрень возникнет, если IDE будет показывать только текущий столбец на экране или как-то так.
Вертикальный case меня не очень беспокоит. А горизонтальный очень. Сейчас размер строк в программе регулярно приближается к 60 символам или переходит через них, если разместить 30 case-случаев по горизонтали, то получится около 2000 символов на строку. К тому же будет теряться очень много полезного места на отступы и выравнивание по столбцам. Это если размещать это в виде обычного текстового файла в таком виде, как это на экране. Если же использовать внутри файла какую-то разметку или какой-то двоичный формат (как тот же флэш), то мы приходим к той же проблеме. Опять-таки жесткая привязка к IDE- не есть хорошо. Программируя на C, я могу пользовать Kdeveloper, Visual Studio, Eclipse или просто тупо набирать программу в Far'е. Здесь такое невозможно.
С другой стороны, флэшерымучаютсяработают и не жужжат -)
«Устройство Windows-приложения не является образцовым примером проектирования» как аргумент не принимается, мы живем в том мире, который есть, и WinAPI ради нового стиля программирования никто переделывать не будет.
Я не вижу особых преимуществ такой двумерной схемы. При переходе c Borland C++ на Delphi преимущества были налицо, а здесь они весьма спорные. Внешне это напоминает переход на другой язык программирования. Примерно как перейти с C++ на Fort или Lisp. К тому же дополнительно нагружаются мозги лишним измерением.
Кстати говоря, не уловил пассаж про «более высокий уровень абстракции». VCL, MFC, Qt- это абстракции по отношению к WinAPI. Таблицы- это иной способ записи программы. К «высоким уровням абстракции» это отношения не имеет.
Имхо- технология сырая. Если ее доведут до ума- будет очень интересно посмотреть.
Вертикальный case меня не очень беспокоит. А горизонтальный очень. Сейчас размер строк в программе регулярно приближается к 60 символам или переходит через них, если разместить 30 case-случаев по горизонтали, то получится около 2000 символов на строку. К тому же будет теряться очень много полезного места на отступы и выравнивание по столбцам. Это если размещать это в виде обычного текстового файла в таком виде, как это на экране. Если же использовать внутри файла какую-то разметку или какой-то двоичный формат (как тот же флэш), то мы приходим к той же проблеме. Опять-таки жесткая привязка к IDE- не есть хорошо. Программируя на C, я могу пользовать Kdeveloper, Visual Studio, Eclipse или просто тупо набирать программу в Far'е. Здесь такое невозможно.
С другой стороны, флэшеры
«Устройство Windows-приложения не является образцовым примером проектирования» как аргумент не принимается, мы живем в том мире, который есть, и WinAPI ради нового стиля программирования никто переделывать не будет.
Я не вижу особых преимуществ такой двумерной схемы. При переходе c Borland C++ на Delphi преимущества были налицо, а здесь они весьма спорные. Внешне это напоминает переход на другой язык программирования. Примерно как перейти с C++ на Fort или Lisp. К тому же дополнительно нагружаются мозги лишним измерением.
Кстати говоря, не уловил пассаж про «более высокий уровень абстракции». VCL, MFC, Qt- это абстракции по отношению к WinAPI. Таблицы- это иной способ записи программы. К «высоким уровням абстракции» это отношения не имеет.
Имхо- технология сырая. Если ее доведут до ума- будет очень интересно посмотреть.
Я не понял как эта поделка позиционируется? Новая нотация для алгоритмов вместо старых блок-схем? Или язык программирования?
как концепция
концепция чего?
Концепция записи логики программы. Входит в состав языка Coherence — академической разработки товарища Джонатана Эдвардса.
Язык программирования нужен, чтобы абстрагироваться от работы процессора, чтобы речью (английской обычно) объяснить процессору что делать.
Все эти схемы не похожи на то, как описывают издавна алгоритмы: «Варить до готовности» — варить() пока! готово?, «А коли дань платить не будете, войско наше на земли ваши вступит» — напасть если! дань_уплачена, определённый интеграл — с A до B с шагом dx…
Даже если научиться их читать и писать — всё равно в голове будут те же if, switch, while.
Все эти схемы не похожи на то, как описывают издавна алгоритмы: «Варить до готовности» — варить() пока! готово?, «А коли дань платить не будете, войско наше на земли ваши вступит» — напасть если! дань_уплачена, определённый интеграл — с A до B с шагом dx…
Даже если научиться их читать и писать — всё равно в голове будут те же if, switch, while.
Сначала верстали на таблицах, теперь программируют… Даешь теперь <div>'ное программирование!
в любом случае, визуальное программирование какими-то блокс-хемами — это будущее, имхо. в том или ином виде…
У кого-нить exe запустился? Падает с «ошибкой при инициализации» 0xc0000135, вин xp pro 2002 sp3.
Мне нравиться.
Мне нравиться.
Не привязываясь к конкретной нотации: иногда необходимо приподняться над привычным способом чего-то делать и посмотреть на это под другим углом.
Не далее как несколько дней назад, убил времени на написание достаточно запутанной логики. Потом сел, подумал, начертил таблицу, разметил условия и переходы, фактически нарисовал конечный автомат. После того как всё встало на свои места, перенести это в обычную нотацию обычного языка программирования — было делом исключительно тривиальным.
Правда, я не возьмусь объяснить кому-бы то ни было как работает получившийся фрагмент кода, без привлечения табличного представления этого автомата.
Не далее как несколько дней назад, убил времени на написание достаточно запутанной логики. Потом сел, подумал, начертил таблицу, разметил условия и переходы, фактически нарисовал конечный автомат. После того как всё встало на свои места, перенести это в обычную нотацию обычного языка программирования — было делом исключительно тривиальным.
Правда, я не возьмусь объяснить кому-бы то ни было как работает получившийся фрагмент кода, без привлечения табличного представления этого автомата.
По сравнению с ООП таблички очень сильно проигрывают в больших проектах.
Как альтернативное представление кода для задач отладки и оптимизации — тоже не хватает наглядности. Для проектирования тоже не подходит…
Надеюсь, найдется достойная сфера применения.
Как альтернативное представление кода для задач отладки и оптимизации — тоже не хватает наглядности. Для проектирования тоже не подходит…
Надеюсь, найдется достойная сфера применения.
В заголовке фигурирует фраза «концепция записи условных (и не только) конструкций».
В материале освещены как раз только условные. Можно пример «не только условных»? А то С, С++, C#, Java, VB да и вообще все остальные распространенные языки оперируют не только условными конструкциями. И полиморфизм сравнивать с такой таблицей я бы не стал, ибо у него множество более полезных применений, чем то, в котором его может якобы заменить такая концепция.
В материале освещены как раз только условные. Можно пример «не только условных»? А то С, С++, C#, Java, VB да и вообще все остальные распространенные языки оперируют не только условными конструкциями. И полиморфизм сравнивать с такой таблицей я бы не стал, ибо у него множество более полезных применений, чем то, в котором его может якобы заменить такая концепция.
«И не только» — это составление рабочих функций, их выполнение, отладка, составление юнит-тестов, механизм рекурсивных вызовов.
Табличное представление для if/case в данной концепции весьма удобно (мне кажется), если привыкнуть.
А вот «составление рабочих функций, их выполнение, отладка, составление юнит-тестов, механизм рекурсивных вызовов» — можно пример чего-нибудь из этого списка?
Просто такие таблицы не более чем визуальная оболочка. С тем же успехом можно писать на том же C# а для таких вот конструкций сделать визард или возможно даже Debuger Visualizer, упрощающие понимание кода с множеством if-ов и прочее.
В общем, прикольно, интересно, но хз зачем…
А вот «составление рабочих функций, их выполнение, отладка, составление юнит-тестов, механизм рекурсивных вызовов» — можно пример чего-нибудь из этого списка?
Просто такие таблицы не более чем визуальная оболочка. С тем же успехом можно писать на том же C# а для таких вот конструкций сделать визард или возможно даже Debuger Visualizer, упрощающие понимание кода с множеством if-ов и прочее.
В общем, прикольно, интересно, но хз зачем…
«… можно пример чего-нибудь из этого списка?»
Эти вещи я кратко описал в заметке. В частности, составление теста и выполнение функции можно посмотреть в примере с Фибоначчи. Рекурсивные вызовы там же. На видео автор показывает пример ошибки в юнит-тесте (временная отметка 17:20) и демонстрирует, как можно редактировать код функции прямо в процессе ее выполнения.
Эти вещи я кратко описал в заметке. В частности, составление теста и выполнение функции можно посмотреть в примере с Фибоначчи. Рекурсивные вызовы там же. На видео автор показывает пример ошибки в юнит-тесте (временная отметка 17:20) и демонстрирует, как можно редактировать код функции прямо в процессе ее выполнения.
С тем же успехом можно писать на том же C# а для таких вот конструкций сделать визард или возможно даже Debuger Visualizer, упрощающие понимание кода с множеством if-ов и прочее.А Джонатан хочет донести до нас мысль, что такие конструкции можно изначально записывать в таблицах, которые автоматом разрешат противоречивые случаи, а затем преобразовать результат в код и сэкономить таким образом время и затраченные усилия.
Это же академический проект. Вероятнее всего он хорошо подойдет для верификации программ, а не для разработки. Непонятно только что концептуально нового в этом программировании таблиц? На полке лежит книга Э.Хамби Программирование таблиц решений (Programs from decision tables) 1976, не далеко за 35 лет прогресс шагнул (
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программирование в таблицах — новая концепция записи условных (и не только) конструкций