Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Вт мар 19, 2024 09:52

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 113 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8  След.

Куда цеплять "драйвера"?
Создавать лексиконы наподобие Си-библиотек 44%  44%  [ 4 ]
Прятать внутрь интерпретатора 0%  0%  [ 0 ]
Усложнять интерпретатор 0%  0%  [ 0 ]
Использовать более одного интерпретатора 22%  22%  [ 2 ]
FORTH устроен совсем не так 33%  33%  [ 3 ]
Всего голосов : 9
Автор Сообщение
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 28, 2014 11:24 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 323
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 11 раз.
В чём я согласен с gudleifr, в том, что Форту не хватает ещё одного "уровня, слоя" развития, для того, что бы стать реально удобным. Лексиконы, словари, усложнение интерпретатора - это всё детали. Основная проблема в отсутствии стройного "окружения", библиотек, если сказать по старинке. Но это должны быть не те библиотеки, что сейчас имеются (говоря про Форт имею ввиду SPF, как наиболее проработанный) в Форте, а набор взаимосвязанных, оптимизированных модулей, способных стыковаться друг с другом на разных уровнях. Вот для обслуживания таких библиотек (окружения) замечательно подошла бы возможность самого Форта изменять язык и себя.
Пример. Сейчас я практически перешел на "D". Этакое развитие C++. Пока не берем во внимание сам язык, хотя сейчас к нему вернемся. Библиотеки окружения - вот передний край исследований. Даже придумали имя им - "Фобос". Но дело не в этом. Основной вектор развития - это построение как раз следующего СЛОЯ развития языка. Это когда можно взять сверх-высокоуровневый модуль, а можно наоборот простейшую функцию, и что приятно, они взаимодействуют. Так вот если вернуться к Форту, то "бедные" дишники, всю голову сломали как сделать ИНТЕРАКТИВНОСЬ, что бы управлять таким новым слоем, всячески "заворачивают узлом" компилятор, все для того, что бы хоть чуть чуть подойти к возможностям Форта. Например, их "финты" по генерации различных функций на основании динамических шаблонов - это попытка сделать CREATE .... DOES>.
Разработка, стандартизация, документирование такого слоя на Форт - это было бы круто! Что бы не искать парсер XML в сторонних библиотеках, а одной строкой подключил его и был бы уверен, что он максимально использует все возможности Форта и процессора. Слова, - "... есть аналог или можно сделать самому ..." отбрасывают Форт далеко назад.

Пример D. Использованы только стандартные средства и библиотеки. Это я о уровне проработки и языка и библиотек.

Код:
import std.path;
import std.file;
import std.conv;
import std.stdio;
       
int main(string[] args) {
    string str;       
    foreach(str; dirEntries("C:\\", SpanMode.depth)) {
        if(toUpper(extension(str)) == ".TXT") {
            File fNames = File(str, "r");
            writeln(fNames.readln());
            fNames.close();
        }
    }
    return 0;
}           


Всего то, найди все текстовые файлы на C:\ c обходом всех каталогов и напечатай их первую строку.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 28, 2014 11:43 
mgw писал(а):
В чём я согласен с gudleifr, в том, что Форту не хватает ещё одного "уровня, слоя" развития, для того, что бы стать реально удобным.
Наоборот, сила FORTH в том, что этот слой ему не нужен! И даже противопоказан. Это пастбище быдлокодеров - неизбежное зло C-подобных языков.
mgw писал(а):
Даже придумали имя им - "Фобос".
Плагиаторы хреновы. Хорошо хоть по-латински пишут правильно, а не как я.
mgw писал(а):
Что бы не искать парсер XML в сторонних библиотеках, а одной строкой подключил его и был бы уверен, что он максимально использует все возможности Форта и процессора.
Хитрость искусства программирования в том, что уверенным в этом быть нельзя. И если вы базируетесь на этой "уверенности" - значит, вы не понимаете, что делаете. Более того, в случае XML можно быть уверенным в обратном.
mgw писал(а):
Пример D. Использованы только стандартные средства и библиотеки. Это я о уровне проработки и языка и библиотек.
Это беда всех языков для написания простых программ: на них очень легко пишется то, что писать нет никакой нужды. (В данном случае, например, достаточно средств shell). "Бобик - сын Шарика", "Квадрат наследует свойства Фигуры", "рекурсивно разворачиваем список задом наперед"...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 28, 2014 13:47 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 323
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 11 раз.
gudleifr писал(а):
Наоборот, сила FORTH в том, что этот слой ему не нужен! И даже противопоказан. Это пастбище быдлокодеров - неизбежное зло C-подобных языков.

Я в корне не согласен. Что, каждую библиотеку писать самому? Зачем? Что бы дольше и труднее давалась каждая программа? А может без библиотек? Тогда как?

gudleifr писал(а):
Это беда всех языков для написания простых программ: на них очень легко пишется то, что писать нет никакой нужды. (В данном случае, например, достаточно средств shell). "Бобик - сын Шарика", "Квадрат наследует свойства Фигуры", "рекурсивно разворачиваем список задом наперед"...

Вообще не пойму причем тут shell? Вроде как речь о Форте. Что значит "язык для написания простых программ"? Как отличить язык для написания простых программ от языка для написания сложных?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 28, 2014 13:49 
mgw писал(а):
Что, каждую библиотеку писать самому?
Каждую не получится. Так можно дойти до обязательного паяния компьютера... Библиотеки будут всегда. Но относится к ним надо как к неизбежному злу - очередной несовершенной детали аппаратно-программного обеспечения. Требовать их обязательного совершенства - вещь безосновательная. Как и желание "собрать все необходимое".
Перечитайте, например, Кернигана и Пайка "Практика программирования" - там есть пара примеров неспособности всеми принятым библиотеками обеспечить нормальную работу программы. Причем, К&П тут же показывают пример написания библиотеки (глядя на который, то и дело ловишь себя на мысли, что сам бы сделал совсем по-другому...
mgw писал(а):
А может без библиотек? Тогда как?
FORTH предлагает простейшее решение. Понадобилось - прицепи. Не надо делать только универсальный "прицеплятель"...
Возьмем, например, обычную виндовую MessageBox - четыре параметра (два зависят от глубины вложенности этой ф-ии в интерфейс, третий чисто информационный, четвертый управляет видом возвращаемого значения). Если я просто сделаю словом вызов этой ф-ии, то предложения с ее участием будут плохо читаемы (никак не будет отображено своеобразие параметров). Если я, наоборот, напишу универсальную оболочку "win-вызовов" с априори определенными способами обработки стандартно-хитрых параметров, то сложностей в ее применении меньше не станет - все так же придется осмыслять каждый вызов. Выход - создать оболочку для этой ф-ии строго по месту, например, выдачи нужного сообщения по ошибке. Нам будет плевать, насколько сложна эта функция, ведь мы будем знать, что здесь она делает что-то простое. Никакого универсализма!
mgw писал(а):
Вообще не пойму причем тут shell?
К тому, что радоваться что новый язык умеет делать тоже самое, наверное, не стоит.
mgw писал(а):
Что значит "язык для написания простых программ"?
Обычно, это язык, с кучей свистелок и перделок на все типовые случаи. Изначально BASIC: графика, музыка, прочее железо, обезьянник... Туда же SmallTalk, Tcl/Tk, Perl, Java, Python...
Чем отличаются языки "для сложных программ"? В них упор делается не на заранее заготовленный набор интерфейсов, а на возможность почти-математического доказательства правильности писания... В конечном случае, возможность создания более-менее строгого проблемно-ориентированного языка.
Особенно выделяются FORTH и C++ (но у последнего есть изъян - любой язык, на нем написанный, будет тем же C++). Обычный C не является таким языком в чистом виде, но вкупе со всей "механикой" 'nix-ов,- гораздо мощнее чистого C++.
(Кстати, обратите внимание, библиотеки C частью языка не являются).


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 28, 2014 15:22 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 323
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 11 раз.
Замкнутый круг. Нет библиотек (типа каждый делает сам), как следствие десятки реализаций одного и того же (причем узкоспециализированного назначения). В результате написание почти любой программы превращается в " ... если чего то нет, всегда можно дописать самому ...", а это лишние трудности. А ведь Форт позиционируется как "быстрое и простое", а на практике получается совсем не простое и тем более не быстрое. А как следствие этого, отсутствие базиса для дальнейшего развития. Вот и получается, что дальше простеньких примеров дело не идет. Сейчас не сколько важен язык программирования, сколько его окружение. Пример: Java и C++ - океаны библиотек на любой вкус. Какой бы гениальности не был язык, без окружения он не жизнеспособен.
Я не ругаю Форт, он гениален. Но только как механизм самосовершенствования, а не как прикладной язык программирования.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 28, 2014 18:22 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Сейчас, под старость, мне кажется, что эта граница в C-подобных языках - два уровня (по молодости, кажется, была выше)...
Т.е., допустим, я пишу программу строковой обработки и свободно использую string.h (все эти strcpy и strcmp). Я вполне свободно формулирую задачу в терминах этих операций, понимаю, что они делают и какие ловушки есть в их использовании...
Но, опять допустим, я наращиваю третий уровень. Использую написанную программу как библиотеку более высокого уровня. И тут, не знаю как у вас, а у меня уже возникают проблемы: я уже перестаю быть уверен, что набор из моих операций, использующих строковые операции, эффективно/правильно делает то, что мне надо. Может проще было прямо вызвать эти самые строковые операции?
Требуется какое-то явное средство доказательства того, что все, что мне нужно правильно "инкапсулировано" на всю глубину вложения. (См., например, Дейкстра "Заметки по структурному программированию").


Вопрос вызова функций - это вопрос тактический. Рано или поздно это отлаживается. Вплоть до определенного размера программы (скажем, 10 тыс. строк) можно не предпринимать специальных усилий по проработке архитектуры.

За этим уровнем (примерно до 50 тыс. строк) проект обычно оказывается настолько сложным, что неминуемо требует сторонних модулей, библиотек, интеграции с другим ПО. Здесь могут потребоваться соглашения о межмодульных интерфейсах, управление пространством имен и какие-то механизмы управления ресурсами. Например, все любят имена переменных X и Y. В Форте легко можно иметь их в нескольких последовательно подключаемых модулях, причем внутри модулей все скомпилируется правильно, а в режиме интерпретации будет видно совсем не то, что ожидается. В данном случае проблема все еще решается вынесением части функционала в отдельный словарь (скрываем из области видимости) и да, заведением вспомогательных интерпретаторов, возможно, совместно с DSL.

Больше 50 тыс. строк мне трудно оценивать трудоемкость и проблемы. Отмечают трудности с интеграцией, масштабированием (обработка массива в 4 кб явно отличается от обработки массива в 4 Тб), эффективность кодирования отступает на второй план по сравнению с эффективностью связей между участниками проекта. Видимо, на этом уровне Форт, концентрирующий усилия на DSL и гибком управлении параметрами кода, уже не имеет такой привлекательности, как любой инструмент, обеспечивающий сборку мусора, управление версиями и интеграционное тестирование.

gudleifr писал(а):
Хищник писал(а):
Если теперь надо архивировать файл, и на входе параметр - имя архивируемого файла, то интерактивности в целом и нет.
Как бы, это только кажется.
Например, помню когда писал для себя последнюю gif-библиотеку, интерактивность потребовалась дважды:

Я не имел в виду, что для архиватора не надо управлять никакими параметрами. Я хотел привести в качестве примера некую задачу, которая достаточно сложна, но при этом стандартна. Поэтому нам интересно просто вызвать ее. В данном случае мы выбираем библиотеку ради функциональности, а остальное (размер, быстродействие), является приемлемым.

В сложных проектах драйвер вполне может выступить в качестве именно такого кирпичика, изменение которого приведет к малозначимым улучшениям (несущественно с точки зрения задачи, или же узким место является аппаратная часть), однако попытка переписать код связана с риском получить лишь частично работоспособное решение. Однако это не касается ключевых фрагментов кода, относящихся к тому, что, собственно, и является целью проекта.



За это сообщение автора Hishnik поблагодарил: mgw
Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 28, 2014 20:54 
Хищник писал(а):
...
Это только "общепринятое манагерское мнение". Причем, интересно, тем более политическое, чем конкретнее рассматриваемый технический вопрос.

Особенно умилило "50т.строк". Т.е. около 1000 страниц. Много вы знаете людей, способных рассмотреть это "как единое целое"? Связать каждое действие героев "Войны и Мира" с конкретной страницей, где оно описано?
Обычно "программы" такого размера - это просто длинная последовательность следования какому-либо ручному/моделируемому процессу. С добавлением на каждом этапе необходимых интерфейсов и настроек. Жуткая избыточность и очень малая смысловая связность... (Если вернуться к моим "двум уровням", то здесь мы имеем, скорее, "полтора уровня", т.к. демиург сего шедевра обычно не ведает, что делают его "подпрограммы").

Провел "эксперимент": первая версия Star Trek на BASIC - ок. 500 строк вместе со всей документацией, FORTH - полторы тысячи строк, C - 7 тыс.строк только в C-файлах, Python - столько же в основном файле. Функционал, я так понял, немного расширялся от версии к версии, но, все равно, какова цена таким подсчетам?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Пн апр 28, 2014 21:46 
mgw писал(а):
Замкнутый круг. Нет библиотек (типа каждый делает сам), как следствие десятки реализаций одного и того же (причем узкоспециализированного назначения). В результате написание почти любой программы превращается в " ... если чего то нет, всегда можно дописать самому ...", а это лишние трудности.
Не надо передергивать. В ситуации, когда все уже написано и нужно только привязать написанное к пропертям и эвентам, программист вообще не нужен...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вт апр 29, 2014 01:42 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Особенно умилило "50т.строк". Т.е. около 1000 страниц. Много вы знаете людей, способных рассмотреть это "как единое целое"? Связать каждое действие героев "Войны и Мира" с конкретной страницей, где оно описано?
Обычно "программы" такого размера - это просто длинная последовательность следования какому-либо ручному/моделируемому процессу. С добавлением на каждом этапе необходимых интерфейсов и настроек. Жуткая избыточность и очень малая смысловая связность... (Если вернуться к моим "двум уровням", то здесь мы имеем, скорее, "полтора уровня", т.к. демиург сего шедевра обычно не ведает, что делают его "подпрограммы").

Если посмотреть внимательнее, я отметил, что до 10 тыс. строк архитектура как таковая пока не играет роли, а вот в диапазоне 10-50 тысяч уже действительно появляется необходимость рассматривать компоненты программы в качестве крупных строительных блоков. 50 тысяч - это моя осторожная оценка, я встречал в качестве верхнего предела и 300 тысяч строк. Разумеется, в этом случае не до отдельных подпрограмм, они предполагаются работающими как положено. Здесь же появляется разделение на юнит-тесты и интеграционные тесты (если подпрограмма все-таки не работает, достаем юнит-тест и начинаем отлаживать ее на очевидных примерах, а потом возвращаемся к проекту целиком).

gudleifr писал(а):
Провел "эксперимент": первая версия Star Trek на BASIC - ок. 500 строк вместе со всей документацией, FORTH - полторы тысячи строк, C - 7 тыс.строк только в C-файлах, Python - столько же в основном файле. Функционал, я так понял, немного расширялся от версии к версии, но, все равно, какова цена таким подсчетам?

А что можно узнать на основе такой выборки? Программы бывают самые разные, и требования к ним диктуются не столько интересами программистов, сколько потребностями окружающих. Драйверы некоторых устройств объективно сложны, просто алгоритмически. Форт может способствовать созданию удобного для программиста инструментария, но не совершит чуда и не уберет эту алгоритмическую сложность.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вт апр 29, 2014 07:28 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
KPG писал(а):
Как писать/понимать произвольный программный код не прилагая к этому чрезмерных усилий?
Использовать родной язык и удобную инструментальную среду. Лучше всего - программно-аппаратный комплекс дополненной(или виртуальной) реальности. Использовать все органы чувств для создания аналогий. Ну и достаточно часто этим заниматься! ;)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вт апр 29, 2014 10:20 
Хищник писал(а):
Если посмотреть внимательнее, я отметил, что до 10 тыс. строк архитектура как таковая пока не играет роли, а вот в диапазоне 10-50 тысяч уже действительно появляется необходимость рассматривать компоненты программы в качестве крупных строительных блоков.
Думаю не так. Скорее, понятие "архитектура" здесь настолько ничего само по себе не значит, что говорить о 10000, 50000 или 1000000 строк - безразлично.
gudleifr писал(а):
А что можно узнать на основе такой выборки?
Только то, что я написал: оценка просто "по строкам" смысла не имеет.
Хищник писал(а):
Здесь же появляется разделение на юнит-тесты и интеграционные тесты (если подпрограмма все-таки не работает, достаем юнит-тест и начинаем отлаживать ее на очевидных примерах, а потом возвращаемся к проекту целиком).
При таких размерах тестирование уже может производится единственным методом: "обезьян с пишущими машинками".
gudleifr писал(а):
Драйверы некоторых устройств объективно сложны, просто алгоритмически. Форт может способствовать созданию удобного для программиста инструментария, но не совершит чуда и не уберет эту алгоритмическую сложность.
Алгоритмическая сложность? Помните "1%" Мура?

in4 писал(а):
Использовать родной язык и удобную инструментальную среду.
Нет, нужно предпринимать вполне очевидные меры по формализации конструирования.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вт апр 29, 2014 16:41 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
gudleifr писал(а):
Думаю не так. Скорее, понятие "архитектура" здесь настолько ничего само по себе не значит, что говорить о 10000, 50000 или 1000000 строк - безразлично.

Сравним стековую нотацию двух слов, рисующих прямоугольник

Код:
x, y, ширина, высота --
x, y, ширина, высота, цвет_линии, толщина_линии, цвет_заливки, есть_заливка, радиус_скругления, штриховка, цвет_штриховых_линий --


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

В каком случае вероятнее появление такой чехарды - при 1000 строках или при 10000? Видимо, чем больше строк, тем вероятнее усложнение взаимосвязей между отдельными словами. Поэтому желательно было бы заранее продумать, что именно слова могут друг другу передавать, и как это лучше сделать. Например, путем ввода переменных, автоматически применяющих свои текущие параметры к рисованию прямоугольника. Тогда для изменения толщины линии нужно будет вызвать слово УСТАНОВИТЬ_ТОЛЩИНУ_ЛИНИИ. С другой стороны, если все прямоугольники - белые на черном фоне, то реализация всего набора этих слов будет избыточной. Это еще не вполне "архитектура", но пример постановки проблемы. И 10 тысяч - не какое-то магическое число, после которого начинаются проблемы, а вполне размытая граница в стиле нечеткой логики.

gudleifr писал(а):
При таких размерах тестирование уже может производится единственным методом: "обезьян с пишущими машинками".

Как раз при таких размерах и начинается тестирование. Крайние случаи, вырожденные случаи, good path (все по инструкции), bad path (постоянно то файла нет, то ввели не то и не того типа). Да, псевдослучайные последовательности (не только получаемые генератором псевлослучайных чисел, а еще и просто детерминированные, но нерегулярные).

gudleifr писал(а):
Алгоритмическая сложность? Помните "1%" Мура?

А что с "1% Мура" и когда это стало преобладать в индустрии? Если Мур захочет уложить в 64 слова стек TCP/IP, его не спасут никакие лозунги о правильном мышлении и мощи Форта. Если требуется цикл по массиву в 1000 элементов и три условных перехода, то это так и будет на любом языке.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вт апр 29, 2014 17:00 
Хищник писал(а):
Сравним стековую нотацию двух слов, рисующих прямоугольник...
Вот тут уже ошибка. В сложной программе заведомо будут ОБА варианта! И еще пара-другая, среди которых, опять заведомо, будут совершенно одинаковые, только с разными именами.
Хищник писал(а):
Как раз при таких размерах и начинается тестирование.
Как бы, все специфические/рекомендуемые тесты (типа перечисленных Вами ниже) при таких размерах уже не работают. Просто невозможно обособить тот блок, для которого они будут "граничными" или "выроджденными".
gudleifr писал(а):
А что с "1% Мура" и когда это стало преобладать в индустрии?
Как бы Мур и жалуется на это самое "преобладание".
Индустрия? Подарил тут маме очередную читалку. И заодно посмотрел на нее со стороны. Почему она так тормозит? Откуда эти ложные срабатывания? Почему нет синхронизации нажатия на кнопку с фактом существования этой самой кнопки? Куда девается заряд батарейки? Нет, это не "индустрия" научилась создавать сложные программы, это просто мы привыкли к тому, что она этого не умеет...

P.S. Опять мы с чисто технического вопроса перешли на чисто философскую тему...


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вт апр 29, 2014 21:20 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 323
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 11 раз.
С читалками все понятно. Не понятно как написать большую и сложную программу, типа ОС, опираясь на парадигмы всеупращения. Для сложных задач нужны другие подходы, и главное ИНСТРУМЕНТЫ, коих в Форте крайне мало. Хотя я сейчас говорю о SPF, а есть и другие реализации форта, они имеют более продвинутое окружение. У VFXforth например, очень даже продвинутые библиотеки окружения. Их бы в SPF записать, уже был бы огромный шаг вперёд. Читая документацию по D меня просто поразило, сколько они предприняли усилий именно для создания таких инструментов-механизмов. Времена Мура позади, тогда ресурсы компьютера были другими и как следствие, другие подходы к программированию.

Кстати, драйвера надо цепляться в модуль ввода/вывода, иначе все останется набором лексиконов.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: От FORTH - к OS
СообщениеДобавлено: Вт апр 29, 2014 21:39 
mgw писал(а):
С читалками все понятно.
Читалка - только повод взглянуть на современный дебильник глазами человека, выросшего во времена, когда проблема машины считалась недоработкой конструктора, а не недопродвинутостью пользователя. Мои домашние компы тоже глючные, просто я к ним привык... (Окромя КПК на Винде, который настолько хуже моих старых Palm-ов, что привыкнуть к этому невозможно...)
mgw писал(а):
Не понятно как написать большую и сложную программу, типа ОС...
Читалки всяко имеют на борту ОС.
mgw писал(а):
Для сложных задач нужны другие подходы, и главное ИНСТРУМЕНТЫ, коих в Форте крайне мало.
Наоборот, в FORTH мало привычных инструментов для простых задач: драйверов, обезьянников, библиотек... В сложной задаче доля "драйверов" - самая пустяковая, это в простых они занимают большую часть кода. Проблема не в наличии/отсутствии драйверов, а в необходимости сложного управления ими...
mgw писал(а):
Кстати, драйвера надо цепляться в модуль ввода/вывода, иначе все останется набором лексиконов.
Это уже почти по теме, но у FORTH нет модуля ввода/вывода. Правда, такого модуля нет почти ни у кого, разве, что уж у совсем честно 'nix-овских программ, заточенных под stdin/stdout.


Вернуться к началу
  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 113 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB