Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
Посмотрев описание концепций Thyrd среды (даже через перевод гугловского транслятора) Есть в этом подходе, определённо рациональное начало для дальнейшего субъективного осмысления. P.S. Хотелось бы ещё понять о чём расказывает разработчик данной концепции в видео-презентации и на каких частностях он акцентирует внимание + насколько предложенный способ представления и оперирования данными универсален. Возможно, наверное, к этому дизайну "прицепить", например, и язык Factor. У кого какие есть мнения? Жалко что не видно продолжения разработки с момента публикации.
Посмотрев описание концепций [url=http://thyrd.org]Thyrd[/url] среды (даже через перевод гугловского транслятора) Есть в этом подходе, определённо рациональное начало для дальнейшего субъективного осмысления.
P.S. Хотелось бы ещё понять о чём расказывает разработчик данной концепции в видео-презентации :) и на каких частностях он акцентирует внимание + насколько предложенный способ представления и оперирования данными универсален. Возможно, наверное, к этому дизайну "прицепить", например, и язык Factor. У кого какие есть мнения? Жалко что не видно продолжения разработки с момента публикации.
|
|
|
|
Добавлено: Пт окт 02, 2015 19:55 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
in4 писал(а): А если низкоуровневая реализация (интерпретатор ШК или подпрограммный код) будет традиционной, просто добавится еще "интерпретатор" визуального представления? А чем это будет отличаться от того, о чем говорил коллега Хищник? in4 писал(а): Под "мощностью" я имел ввиду функциональные возможности. Они упадут неизбежно. Основная прелесть FORTH - минимальная избыточность программного текста, позволяющая немного отодвинуть границу сложности. Увеличив сложность языка, вы уменьшаете допустимую сложность программ. in4 писал(а): с дополнительным функционалом - подсказки, анализ, генерация исходников, рефакторинг и т.п. . Как бы ничего этого FORTH не нужно. В смысле "обычных" или "стандартных". А необычные/нестандартные определяются текущей решаемой задачей.
[quote="in4"]А если низкоуровневая реализация (интерпретатор ШК или подпрограммный код) будет традиционной, просто добавится еще "интерпретатор" визуального представления?[/quote]А чем это будет отличаться от того, о чем говорил коллега [b]Хищник[/b]? [quote="in4"]Под "мощностью" я имел ввиду функциональные возможности.[/quote]Они упадут неизбежно. Основная прелесть FORTH - минимальная избыточность программного текста, позволяющая немного отодвинуть границу сложности. Увеличив сложность языка, вы уменьшаете допустимую сложность программ. [quote="in4"]с дополнительным функционалом - подсказки, анализ, генерация исходников, рефакторинг и т.п. .[/quote]Как бы ничего этого FORTH не нужно. В смысле "обычных" или "стандартных". А необычные/нестандартные определяются текущей решаемой задачей.
|
|
|
|
Добавлено: Ср май 21, 2014 09:44 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
gudleifr писал(а): Т.к. "визуальный стек" будет, явно, реализован по-другому, DUP и DROP будут там бесполезны. А если низкоуровневая реализация (интерпретатор ШК или подпрограммный код) будет традиционной, просто добавится еще "интерпретатор" визуального представления? Если этот интерпретатор (входными данными для него будут не тексты, а списки адресов(?) визуальных структур) будет давать ровно тот же результат, что и обычный интерпретатор? gudleifr писал(а): "Мощность" как раз пострадает, т.к. снабжение графическим интерфейсом столь простых сущностей здорово утяжелит систему, неизбежно ограничивая возможности программиста. Под "мощностью" я имел ввиду функциональные возможности. С учетом того, что я сказал выше, они пострадать не должны. Возможна некоторая потеря скорости, но пока кажется, что возможен даже некоторый выигрыш, если использовать прекомпилированные исходники (как у Мура в colorForth). Редактор, да, будет медленнее, но в графической среде все обычные текстовые редакторы тяжеловесные... Ограничений программиста не будет, т.к. "визуальность" можно рассматривать как прозрачную надстройку над обычной системой, но с дополнительным функционалом - подсказки, анализ, генерация исходников, рефакторинг и т.п. .
[quote="gudleifr"] Т.к. "визуальный стек" будет, явно, реализован по-другому, DUP и DROP будут там бесполезны.[/quote]А если низкоуровневая реализация (интерпретатор ШК или подпрограммный код) будет традиционной, просто добавится еще "интерпретатор" визуального представления? Если этот интерпретатор (входными данными для него будут не тексты, а списки адресов(?) визуальных структур) будет давать ровно тот же результат, что и обычный интерпретатор? ;) [quote="gudleifr"] "Мощность" как раз пострадает, т.к. снабжение графическим интерфейсом столь простых сущностей здорово утяжелит систему, неизбежно ограничивая возможности программиста.[/quote]Под "мощностью" я имел ввиду функциональные возможности. С учетом того, что я сказал выше, они пострадать не должны. Возможна некоторая потеря скорости, но пока кажется, что возможен даже некоторый выигрыш, если использовать прекомпилированные исходники (как у Мура в colorForth). Редактор, да, будет медленнее, но в графической среде все обычные текстовые редакторы тяжеловесные... ;) Ограничений программиста не будет, т.к. "визуальность" можно рассматривать как [u]прозрачную[/u] надстройку над обычной системой, но с дополнительным функционалом - подсказки, анализ, генерация исходников, рефакторинг и т.п. .
|
|
|
|
Добавлено: Ср май 21, 2014 01:37 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
in4 писал(а): Даже если обычные примитивы ( DUP , DROP ) добавить как визуальные объекты? 1. DUP и DROP это только заплатка, а не основополагающее свойство FORTH-системы. Расплата за использование конкретного кондового представления обобщенного СТЕКА. Т.к. "визуальный стек" будет, явно, реализован по-другому, DUP и DROP будут там бесполезны. 2. "Мощность" как раз пострадает, т.к. снабжение графическим интерфейсом столь простых сущностей здорово утяжелит систему, неизбежно ограничивая возможности программиста.
[quote="in4"]Даже если обычные примитивы ( [b]DUP [/b], [b]DROP [/b]) добавить как визуальные объекты?[/quote]1. DUP и DROP это только заплатка, а не основополагающее свойство FORTH-системы. Расплата за использование конкретного кондового представления обобщенного СТЕКА. Т.к. "визуальный стек" будет, явно, реализован по-другому, DUP и DROP будут там бесполезны. 2. "Мощность" как раз пострадает, т.к. снабжение графическим интерфейсом столь простых сущностей здорово утяжелит систему, неизбежно ограничивая возможности программиста.
|
|
|
|
Добавлено: Вт май 20, 2014 22:19 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
gudleifr писал(а): Описать визуальные объекты такой "FORTH", может, и сможет, но наполнить их осмысленным содержанием - нет. Даже если обычные примитивы ( DUP , DROP ) добавить как визуальные объекты? Вроде, мощность не страдает. Так чем плохо? Только внешним представлением для человека?
[quote="gudleifr"]Описать визуальные объекты такой "FORTH", может, и сможет, но наполнить их осмысленным содержанием - нет.[/quote]Даже если обычные примитивы ( [b]DUP [/b], [b]DROP [/b]) добавить как визуальные объекты? Вроде, мощность не страдает. Так чем плохо? Только внешним представлением для человека? ;)
|
|
|
|
Добавлено: Вт май 20, 2014 21:38 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
Хищник писал(а): Я когда-то такое делал... Я всегда говорил, что интерпретация визуального события и поиск слова в словаре - суть одно и то же. Но это опять не то... Не программирование на FORTH оконного интерфейса и не оконный интерфейс для программирования на FORTH, а по-оконному-устроенный FORTH. Обмен между визуальными объектами через стек, новые визуальные объекты как шитые макросы из более простых... Не слова для работы с визуальными объектами, а визуальные объекты - как единственно возможные в системе "слова". (Почему я и против этой идеи. Описать визуальные объекты такой "FORTH", может, и сможет, но наполнить их осмысленным содержанием - нет. Фантик без конфетки).
[quote="Хищник"]Я когда-то такое делал...[/quote]Я всегда говорил, что интерпретация визуального события и поиск слова в словаре - суть одно и то же. Но это опять не то...
Не программирование на FORTH оконного интерфейса и не оконный интерфейс для программирования на FORTH, а по-оконному-устроенный FORTH. Обмен между визуальными объектами через стек, новые визуальные объекты как шитые макросы из более простых... Не слова для работы с визуальными объектами, а визуальные объекты - как единственно возможные в системе "слова". (Почему я и против этой идеи. Описать визуальные объекты такой "FORTH", может, и сможет, но наполнить их осмысленным содержанием - нет. Фантик без конфетки).
|
|
|
|
Добавлено: Вт май 20, 2014 08:50 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
gudleifr писал(а): Возьмем того же Раскина. Что происходит там при клике на экране? Одно из двух: либо в стек добавляется новое значение - координаты точки, либо выполняется некоторое действие с точками на стеке. А т.к., в зависимости от того, что нарисовано на экране, координаты могут быть преобразованы из одной системы координат в другую (например, из экранных в название больницы, нарисованной в этом месте экрана), а простые действия очевидно могут объединятся в сложные, то, очевидно, идея добавления новых "визуальных слов" напрашивается... Я когда-то такое делал, еще в MS-DOS. Клик на экране вызывает слово, которое определяет границы объекта (предполагается, что он окружен черной рамкой). Полученная прямоугольная область сравнивается с библиотекой визуальных элементов, откуда и понимаем, на чем именно сделан клик. Быстрый эффект, но это не решает проблему взаимодействия компонентов.
[quote="gudleifr"]Возьмем того же Раскина. Что происходит там при клике на экране? Одно из двух: либо в стек добавляется новое значение - координаты точки, либо выполняется некоторое действие с точками на стеке. А т.к., в зависимости от того, что нарисовано на экране, координаты могут быть преобразованы из одной системы координат в другую (например, из экранных в название больницы, нарисованной в этом месте экрана), а простые действия очевидно могут объединятся в сложные, то, очевидно, идея добавления новых "визуальных слов" напрашивается...[/quote] Я когда-то такое делал, еще в MS-DOS. Клик на экране вызывает слово, которое определяет границы объекта (предполагается, что он окружен черной рамкой). Полученная прямоугольная область сравнивается с библиотекой визуальных элементов, откуда и понимаем, на чем именно сделан клик. Быстрый эффект, но это не решает проблему взаимодействия компонентов.
|
|
|
|
Добавлено: Вт май 20, 2014 01:38 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
Хищник писал(а): А какой же вопрос он поднял? См. "Юмор". Там я в шутку провел аналогию между программированием снизу-вверх в FORTH и в визуальном программировании ("объяснив" т.о. привлекательность FORTH для "неокрепших умов"). Коллега же предложил еще немного углубить аналогию, сделав визуальными основные FORTH-механизмы. Возьмем того же Раскина. Что происходит там при клике на экране? Одно из двух: либо в стек добавляется новое значение - координаты точки, либо выполняется некоторое действие с точками на стеке. А т.к., в зависимости от того, что нарисовано на экране, координаты могут быть преобразованы из одной системы координат в другую (например, из экранных в название больницы, нарисованной в этом месте экрана), а простые действия очевидно могут объединятся в сложные, то, очевидно, идея добавления новых "визуальных слов" напрашивается...
[quote="Хищник"]А какой же вопрос он поднял?[/quote]См. "Юмор". Там я в шутку провел аналогию между программированием снизу-вверх в FORTH и в визуальном программировании ("объяснив" т.о. привлекательность FORTH для "неокрепших умов"). Коллега же предложил еще немного углубить аналогию, сделав визуальными основные FORTH-механизмы.
Возьмем того же Раскина. Что происходит там при клике на экране? Одно из двух: либо в стек добавляется новое значение - координаты точки, либо выполняется некоторое действие с точками на стеке. А т.к., в зависимости от того, что нарисовано на экране, координаты могут быть преобразованы из одной системы координат в другую (например, из экранных в название больницы, нарисованной в этом месте экрана), а простые действия очевидно могут объединятся в сложные, то, очевидно, идея добавления новых "визуальных слов" напрашивается...
|
|
|
|
Добавлено: Вт май 20, 2014 00:55 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
gudleifr писал(а): Есть задача - написать язык-переводчик с языка "нормального интерфейса" в язык "убогой визуальности". Визуальность-то не убогая, раз с ней так стремятся уравнять Форт. gudleifr писал(а): Но, повторю. Это совершенно никаким местом не относится к вопросу, поднятому коллегой in4!!! А какой же вопрос он поднял?
[quote="gudleifr"]Есть задача - написать язык-переводчик с языка "нормального интерфейса" в язык "убогой визуальности". [/quote] Визуальность-то не убогая, раз с ней так стремятся уравнять Форт. [quote="gudleifr"]Но, повторю. Это совершенно никаким местом не относится к вопросу, поднятому коллегой in4!!![/quote] А какой же вопрос он поднял? :)
|
|
|
|
Добавлено: Вт май 20, 2014 00:39 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
Хищник писал(а): Поэтому попытки разработать Visual Forth бесперспективны просто по постановке задачи. Почему же? Есть задача - написать язык-переводчик с языка "нормального интерфейса" в язык "убогой визуальности". Почему Вы считаете ее заведомо неразрешимой? Но, повторю. Это совершенно никаким местом не относится к вопросу, поднятому коллегой in4!!!
[quote="Хищник"]Поэтому попытки разработать Visual Forth бесперспективны просто по постановке задачи.[/quote]Почему же? Есть задача - написать язык-переводчик с языка "нормального интерфейса" в язык "убогой визуальности". Почему Вы считаете ее заведомо неразрешимой?
Но, повторю. Это [b]совершенно никаким местом не относится к вопросу[/b], поднятому коллегой [b]in4[/b]!!!
|
|
|
|
Добавлено: Пн май 19, 2014 18:52 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
gudleifr писал(а): У Вас - возможно, но коллека in4 предлагал совсем не это. Не только у меня. Мало того, что для Форта нет визуального конструктора интерфейсов класса Visual Studio, так он еще и неактуален. По причинам, описанным в моем предыдущем сообщении. Поэтому попытки разработать Visual Forth бесперспективны просто по постановке задачи.
[quote="gudleifr"]У Вас - возможно, но коллека in4 предлагал совсем не это.[/quote] Не только у меня. Мало того, что для Форта нет визуального конструктора интерфейсов класса Visual Studio, так он еще и неактуален. По причинам, описанным в моем предыдущем сообщении. Поэтому попытки разработать Visual Forth бесперспективны просто по постановке задачи.
|
|
|
|
Добавлено: Пн май 19, 2014 18:49 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
Хищник писал(а): Вопрос не в Раскине, вопрос в Rapid Application Development... У Вас - возможно, но коллека in4 предлагал совсем не это.
[quote="Хищник"]Вопрос не в Раскине, вопрос в Rapid Application Development...[/quote]У Вас - возможно, но коллека [b]in4[/b] предлагал совсем не это.
|
|
|
|
Добавлено: Пн май 19, 2014 18:42 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
gudleifr писал(а): ИМХО, ближе Раскина с его одномодальным интерфейсом к этой идее никто не подходил. Вопрос не в Раскине, вопрос в Rapid Application Development. Какой бы ни был интерфейс, его надо в чем-то делать. Delphi, QT Creator, Visual Studio дают вполне приемлемый инструмент, перекрыть возможности которого не так уж легко. С Фортом тут будет "то же самое, только на Форте". Ну и зачем решать задачу, которую никто не ставил? Проблема не в том, как нарисовать интерфейс, а в том, как его спроектировать и увязать с логикой программы. gudleifr писал(а): Как бы, преимущества FORTH к реализации программы прямого отношения не имеют, т.к. работают только на этапе ее написания. Например, имеем 100 функций, которые должен запускать пользователь (частично связанных друг с другом). В чисто компилируемом языке придется так или иначе обеспечить запуск всех, потому что иначе они повисают мертвым грузом внутри программы. Для этого нужно разбросать их по пунктам меню, кнопкам, контекстным меню и т.п., насколько хватит фантазии. Плюс к этому имеется некое взаимодействие (например, запуск функции 23 с параметрами, определяемыми функциями 54 и 67). Все это также надо уложить в диалоговые окна, wizard-ы, строки статуса, checkbox-ы и т.д. и т.п. Повторю, это всего лишь для того, чтобы обеспечить запуск, об эргономике пока речь не идет. В отличие от этого, интерпретируемый/скриптовый язык может предоставить в распоряжение пользователя только командную строку, и формально этого достаточно. Графический интерфейс - это уже из разряда удобств, базовая функциональность обеспечена и командной строкой. Поэтому сложность интерфейса потенциально может быть существенно ниже и охватывать только часто используемые или сложные в настройке функции программы, для которых требуется в первом случае быстрый и удобный запуск, а во втором - исчерпывающая визуализация режима, в котором предполагается использование.
[quote="gudleifr"]ИМХО, ближе Раскина с его одномодальным интерфейсом к этой идее никто не подходил.[/quote] Вопрос не в Раскине, вопрос в Rapid Application Development. Какой бы ни был интерфейс, его надо в чем-то делать. Delphi, QT Creator, Visual Studio дают вполне приемлемый инструмент, перекрыть возможности которого не так уж легко. С Фортом тут будет "то же самое, только на Форте". Ну и зачем решать задачу, которую никто не ставил? Проблема не в том, как нарисовать интерфейс, а в том, как его спроектировать и увязать с логикой программы.
[quote="gudleifr"]Как бы, преимущества FORTH к реализации программы прямого отношения не имеют, т.к. работают только на этапе ее написания. [/quote] Например, имеем 100 функций, которые должен запускать пользователь (частично связанных друг с другом). В чисто компилируемом языке придется так или иначе обеспечить запуск всех, потому что иначе они повисают мертвым грузом внутри программы. Для этого нужно разбросать их по пунктам меню, кнопкам, контекстным меню и т.п., насколько хватит фантазии. Плюс к этому имеется некое взаимодействие (например, запуск функции 23 с параметрами, определяемыми функциями 54 и 67). Все это также надо уложить в диалоговые окна, wizard-ы, строки статуса, checkbox-ы и т.д. и т.п. Повторю, это всего лишь для того, чтобы обеспечить запуск, об эргономике пока речь не идет.
В отличие от этого, интерпретируемый/скриптовый язык может предоставить в распоряжение пользователя только командную строку, и формально этого достаточно. Графический интерфейс - это уже из разряда удобств, базовая функциональность обеспечена и командной строкой. Поэтому сложность интерфейса потенциально может быть существенно ниже и охватывать только часто используемые или сложные в настройке функции программы, для которых требуется в первом случае быстрый и удобный запуск, а во втором - исчерпывающая визуализация режима, в котором предполагается использование.
|
|
|
|
Добавлено: Пн май 19, 2014 18:26 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
in4 писал(а): Сделать визуальные объекты(не от ООП!), которые параметры через стек передают и дать возможности их объединять. Получится ВизуалФорт! Хищник писал(а): Мне немного непонятно, зачем так много усилий тратить на решение задачи, которая уже имеет множество удовлетворительных вариантов решения. Ой ли? ИМХО, ближе Раскина с его одномодальным интерфейсом к этой идее никто не подходил. Хищник писал(а): С Фортом можно их только повторить, а вот преимущества от языка проявятся в большей степени в реализации внутренней начинки программы, а не интерфейсов пользователя. Как бы, преимущества FORTH к реализации программы прямого отношения не имеют, т.к. работают только на этапе ее написания. Минимальный интерфейс программиста, конечно, достаточен для FORTH, но почему не подумать о максимальном? Но это уже оффтоп.
[quote="in4"]Сделать визуальные объекты(не от ООП!), которые параметры через стек передают и дать возможности их объединять. Получится ВизуалФорт![/quote][quote="Хищник"]Мне немного непонятно, зачем так много усилий тратить на решение задачи, которая уже имеет множество удовлетворительных вариантов решения.[/quote]Ой ли? ИМХО, ближе Раскина с его одномодальным интерфейсом к этой идее никто не подходил.
[quote="Хищник"]С Фортом можно их только повторить, а вот преимущества от языка проявятся в большей степени в реализации внутренней начинки программы, а не интерфейсов пользователя.[/quote]Как бы, преимущества FORTH к реализации программы прямого отношения не имеют, т.к. работают только на этапе ее написания. Минимальный интерфейс программиста, конечно, достаточен для FORTH, но почему не подумать о максимальном? Но это уже оффтоп.
|
|
|
|
Добавлено: Пн май 19, 2014 16:48 |
|
|
|
|
|
Заголовок сообщения: |
Re: Разработка нового Forth-а |
|
|
Мне немного непонятно, зачем так много усилий тратить на решение задачи, которая уже имеет множество удовлетворительных вариантов решения. Визуальные средства проектирования интерфейсов более или менее хороши. С Фортом можно их только повторить, а вот преимущества от языка проявятся в большей степени в реализации внутренней начинки программы, а не интерфейсов пользователя. При этом Форт еще уменьшает потребность в сложных интерфейсах, поскольку командная строка доступна в тех случаях, когда лишняя кнопка или галочка для простого действия только перегрузит GUI (а в "чистом" GUI вариантов и нет - только кнопки, пункты меню и пр.).
Мне немного непонятно, зачем так много усилий тратить на решение задачи, которая уже имеет множество удовлетворительных вариантов решения. Визуальные средства проектирования интерфейсов более или менее хороши. С Фортом можно их только повторить, а вот преимущества от языка проявятся в большей степени в реализации внутренней начинки программы, а не интерфейсов пользователя. При этом Форт еще [i]уменьшает[/i] потребность в сложных интерфейсах, поскольку командная строка доступна в тех случаях, когда лишняя кнопка или галочка для простого действия только перегрузит GUI (а в "чистом" GUI вариантов и нет - только кнопки, пункты меню и пр.).
|
|
|
|
Добавлено: Пн май 19, 2014 16:31 |
|
|
|
|