OSDev

для всех
Текущее время: 22 дек 2024, 05:32

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 19 ]  На страницу Пред.  1, 2
Автор Сообщение
СообщениеДобавлено: 09 май 2015, 18:45 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1126
Мы еще не обсудили итеративность. Человеку приятно получать результат путем одного нажатия. К примеру как в MathCad. Но есть две проблемы для сложного ввода требуется менять команды. А пользователь должен видеть подсказки какая клавиша за что отвечает. Как следствие рождается мышь и графический интерфейс.
Можно ли сделать СУБД без текстового интерфейса? Да можно к примеру Microsoft Access. Есть даже графические языки программирования.

Для программы Здравствуй мир. событийная модель не нужна. Событийная модель нужна для сложной программы с несколькими входами. А потоковый или конвейерная обработка подразумевает, что у нас есть элементарная программа с одним входом и одним выходом. Или другими словами классическая программа преобразования данных из одного формата в другой.

Но если создать базу, то программирование с любой моделью становится простой. Разбив сложную программу на простые кубики. Описав их можно будет строить сложную программу из кубиков выбирая подходящие по размеру, форме и цвету.


Последний раз редактировалось pavia 09 май 2015, 20:32, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 19:10 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1126
Цитата:
По-моему, потоковый подход выглядит в этом случае более естественным. Конечно событийная модель имеет свои преимущества, но что то они как то от меня ускользают, поэтому у меня возникло желание избавиться от неё где возможно. Ведь придётся для ReadLn делать всю эту возню с Application.ProcessMessages... не знаю.
Это потому что большинство программистов не владеют нужными навыками. Программирование это естественная наука как литература. И уметь оформлять свои мысли компактно надо учиться. В школе не учат событийному программированию. Не учат оформлять автомат компактно. В большой фирме архитектуру придумает ведущий программист или архитектор, а большинство программистов получают небольшие задания которые и реализуют. Вот и получается что большинству этот навык не нужен.
Есть хорошая "Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес- Приемы объектно-ориентированного проектирования. Паттерны проектирования." Примеры так себе, но там есть идеи и мысли которые позволяют сделать так что-бы мысль была лаконична.
Цитата:
В случае же с событийной моделью имеем обработчики, разбросанные по разным участкам кода, что размывает логику

Для того что-бы логика в конце концов не размывалось используют аналогию. Для придания границы или формы аналогия заключается в объект. А что-бы пользоваться задают имя объекту. Используя имя можно легко узнавать объект. А также и логику работы.

Так что написать кратко можно. Вот на псевдо-языке.

Код:
modul MyHelloWord in(Name:SignalString) out(Text:SignalString);
begin
Text:='Hello' + Name;
end;

modul main;
begin
MyHelloWord(InputKeyboard.AsString)(Screen.Write); // Соединяем блок с другими блоками.
end;


Стоит сказать что язык основан на описании аппаратуры. Где модуль можно рассматривать как функцию или как микросхему. А сигнал как провод соединяющие разные элементы(модули, микросхемы). А так же сигнал является событием. MyHelloWord - обработчик события.
Внутренняя организация не показана. Но событие можно рассматривать как сообщение или как вызов функции.


Последний раз редактировалось pavia 09 май 2015, 19:50, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 19:50 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Цитата:
Человеку приятно получать результат путем одного нажатия.


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

Цитата:
Мы еще не обсудили итеративность.


Следует сначала сказать пару слов по поводу сложности программы: я вижу разделение программ на консольные и "сложные". Так вот, консольные программы должны хорошо вписываться в консоль, а если программа требует какого то особенного взаимодействия с пользователем, то не стоит её пытаться впихнуть в консоль силой. Сложные программы должны использовать другие модели взаимодействия с пользователем, многооконные там, например. И как они там работают, уже не рассматривается. Вернёмся к консольным программам. Интерактивность консольных программ по сути сводится к возможности мгновенного отображения информации и возможности ввода строк (ReadLn). Использование мыши не рассматриваем, т.к. это уже получается слишком большая интерактивность. По сути всё? Можно ещё что то простое придумать кроме ReadLn/WriteLn? А может быть и ReadLn лишний? Ведь если подумать, при работе со стандартными командами, они никогда не запрашивают дополнительного ввода.

Единственное что мне не нравится - это то, что если реализовывать ReadLn на, к примеру, delphi vcl, с формой и двумя memo, то придётся дёргать Application.ProcessMessages а после ввода строки в memo, непонятно как её вернуть из этого кода. Вернее способы то есть, но они кажутся какими то некрасивыми. Или главное чтобы работало? WriteLn кстати также потребует дёргать Application.ProcessMessages, чтобы отрисоваться непосредственно в момент своего вызова.

И дело не в том, что кто то не владеет нужными навыками, а в том, чтобы не превращать цикл обработки команд (REPL) в кучку обработчиков, разбросанных по разным местам.

Присоединяюсь к рекомендации прочитать книжку по паттернам проектирования. Классика ООП.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 22:04 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1126
Цитата:
Применительно к оболочке я не вижу способа выполнять команды с помощью одного нажатия.

Вы узко мыслите. Можно запросто использовать контекстную подсказку. Как в командоре Нортона или командоре Волкова. А с учетом широкоформатного монитора её можно вообще разместить справа 3 панелью.


В Unix есть текстовый командер Midnight_Commander.
А еще самая известнай утилита top, она тоже является программой с текстовым интерфейсом(TUI).

И есть тестовый редактор vi для ввода или изменения текста в файл. В скрипт или конфигурационный файл. vi тоже TUI, но не имеет подсказок из-за чего я его досихпор не освоил.

Вот для таких программ предусмотрены esc-коды в которых подмешивается цвет символов. А также команды для перемещения текстовый каретки в новую позицию(вы про goto спрашивали, вот это я и имел ввиду).

Я с вами согласен что пихать в консоль это не стоит.

Цитата:
По сути всё? Можно ещё что то простое придумать кроме ReadLn/WriteLn? А может быть и ReadLn лишний? Ведь если подумать, при работе со стандартными командами, они никогда не запрашивают дополнительного ввода.
Нужно знать назначения консоли.

В *nix это работа с файлами. А там команды сложные. К примеру Получить список файлов отсортировать его к примеру по типу. Взять файлы с нужном типом произвести поиск по содержимому. А после просуммировать размер файлов у которых есть вхождение.
Если суммарный размер меньше чем на диске D то скопировать файлы.

Не буду вдаваться в подробности. Но *unix утилиты таковы что обрабатывают поток команд. Он может меняться по ходу работы и быть бесконечным.
Так что нужно или нет решать вам. Но тогда вопрос для чего вам консоль?

Цитата:
Единственное что мне не нравится - это то, что если реализовывать ReadLn на, к примеру, delphi vcl, с формой и двумя memo, то придётся дёргать Application.ProcessMessages а после ввода строки в memo, непонятно как её вернуть из этого кода. Вернее способы то есть, но они кажутся какими то некрасивыми. Или главное чтобы работало? WriteLn кстати также потребует дёргать Application.ProcessMessages, чтобы отрисоваться непосредственно в момент своего вызова.

Честно не понял вопроса. Зачем вызывать Application.ProcessMessages и зачем возвращать?
Безусловно где-то внутри реализации memo вызывается аналог Application.ProcessMessages.

Есть мой любимый шаблон проектирования MCV (модель-контролёр-отображение). Практически любую программу можно разделить на 3 составляющие.

В Delphi достаточно фильтровать ввод(контролер). Складировать в модель вернее в переменную строкового типа. А по приходу enter отдавать модель(строку) на отображение.


Цитата:
И дело не в том, что кто то не владеет нужными навыками, а в том, чтобы не превращать цикл обработки команд (REPL) в кучку обработчиков, разбросанных по разным местам.

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

К примеру команда "дата?"

файл содержащий модуль дата
Код:
TDate=record
          день:ВДень;
          месяц:ВМесяц;
          год:ВГод;
          end;

function GetDate:TDate;
function DateToStr(Date):String;



файл содержащий модуль консоли
Код:
 TCMDLex=record
  qwery:String;
  CMD:String;
  Par1,par2,par3,par4:String;
  end;

Обработчик команды 'дата?'
CmdDate;
begin
WriteLn(DateToStr(GetDate));
end; 

//разборщик(парсер) командой строки
procedure ParseCMD(Cmd,CMDLex);
begin
...
end;

procedure  DoCMD(CMDLex)
begin
  if CmdLex.qwery='?' then
     begin
       Case CMD of
       дата: CmdDate;
       end; // case
     end; // if
end;



файл содержащий модуль терминала
Код:
procedure MainLoop;
var
  s:String;
begin
  repeat
    s:=ReadStr; // Читаем командную строку
    ParseCMD(s, CMDLex);
    DoCMD(CMDLex);
  until False;
end;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 09 май 2015, 23:27 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Вот MC, VC, vi, top - это и есть "сложные" программы в терминологии моего предидущего поста. Потому что они уже работают не по принципу потока, а по принципу вывода в буфер (причём не имеет значения, через какие костыли это реализовано, через esc-последовательности или через вывод backspace-ов). Такие программы пока не рассматриваем в контексте создания простой оболочки, им можно будет дать доступ к буферу напрямую чтобы они лепили что им захочется.

Цитата:
Нужно знать назначения консоли.


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

Цитата:
Зачем вызывать Application.ProcessMessages и зачем возвращать?


Рассмотрим твой же пример: (давай на "ты")

Код:
procedure MainLoop;
var
  s:String;
begin
  repeat
    s:=ReadStr; // Читаем командную строку
    ParseCMD(s, CMDLex);
    DoCMD(CMDLex);
  until False;
end;


Если бы это была событийно-ориентированная программа, например, на delphi vcl, то код MainLoop распался бы на кусочки: цикл бы исчез а ParseCMD и DoCMD переехали бы в обработчик OnKeyPress для командного memo. Если использовать событийно-ориентированный код, тогда мы не сможем вообще вызвать ReadStr, т.к. его у нас не будет вообще в явном виде, будет только реакция на нажатие enter в командном memo. Из-за этого станет невозможным выполнение кода типа (Name := ReadLn; WriteLn('hello, ' + Name);), а также любого другого кода, который пытается запросить пользовательский ввод, в частности нельзя будет рекурсивно запустить командный интерпретатор. Понимаешь о какой проблеме я говорю? А если мы оставляем цикл в коде MainLoop как предложено, то вопрос в том, что скрывается за ReadStr и WriteLn (код, как говориться, в студию). В этом вся соль. И в том, нужен ли вообще ReadLn, и в какой он должен быть форме.

В терминологии MVC, M - это документ консоли (список строк), V - это текстовый буфер, а C - это собственно код управления, включающий как логику (MainLoop), так и утилиты (ReadLn, WriteLn). Только это никак не помогает решить озвученные мною вопросы, потому что не даёт ни единственного намёка на то, как всё таки делать ReadLn и WriteLn, и целесообразно ли вообще делать ReadLn.

Да, в целом задача очень узкая, но достаточно глубокая. С одной стороны, у нас есть текстовый буфер 80*25 и поток скан кодов с клавиатуры, а с другой стороны надо сделать нечто, с чем сможет взаимодействовать оператор, в смысле вводить текст команд и наблюдать результат их выполнения. И желательно в один поток (всмысле не многопоточное решение) и без таймеров. Причём вроде как всё просто, но есть некоторые нюансы, о которых эта тема.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 10 май 2015, 06:23 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 241
Откуда: Санкт-Петербург
dragon писал(а):
Если подразумевается html-ная форма с полем ввода для запроса, мне бы хотелось нечто более интерактивное.

И да, и нет. Что-то простое вроде phpMyAdmin -- это вырожденный случай СУБД-шной админки, но даже он позволяет работать привычным СУБД-шным способом, поскольку нужные абстракции обеспечиваются самой СУБД.

dragon писал(а):
Консольные приложения пишутся довольно легко потому что там есть ReadLn/WriteLn. Логика приложения становится тривиальной: (ReadLn -> Eval -> WriteLn) * loop; В случае же с событийной моделью имеем обработчики, разбросанные по разным участкам кода, что размывает логику.

Мну настолько велик нагл, что посоветует перечитать тему "Hello, world!" на Канторе, держа в голове свои мысли и высказанное ранее в этой теме. Применением ФП и СУБД-шной логики я и пытаюсь добиться правильного абстрагирования. После разговора, думаю, тема окончательно прояснится. Вчера меня классно срубило, прошу простить. :oops:

pavia писал(а):
Мы еще не обсудили итеративность. Человеку приятно получать результат путем одного нажатия.

Это один из тех редких случаев, когда pavia прав. Да, в командной среде интерактивность очень важна. В СУБД-шном интерфейсе она есть.

_________________
Путь успеха Циолковского — правильно умереть


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 10 май 2015, 12:34 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Ну если бы мне нужно было сделать поле для ввода и html-документ для вывода, вопросов бы не стояло (вернее стоял бы вопрос где достать htmlview). Меня интересует, что нахлобучить сверху, чтобы оператор чувствовал себя как рыба в воде. Причём тонкость в том, что ZUI и прочие навороты, они уже слишком сложны для реализации (всмысле мне лень делать эту функциональность в консоли). Это относится и к кантору - я не хочу тянуть свою консольку на такой высокий уровень. Мне нужен набор простых, проверенных, удобных и дешёвых в реализации идей. Ну, непроверенные идеи, но перспективные и дешёвые в реализации тоже рассмотрю.

Да, понятно, что если реализовать всё в функциональном стиле, чтобы получилось "гадить в консоль функции на Канторе не смогут из-за ФП". Но тогда нельзя будет ни ReadLn вызыать ни WriteLn. Но мне кажется это уже настолько далёкая парадигма, что я даже не знаю. О ReadLn я уже говорил в предидущих сообщениях. Какая разница, кто будет писать в консоль, сам интерпретатор или дочерние функции? Для чистоты кода разница есть, а для того, кто пишет саму консоль - не существенно. Причём для оператора это тоже по-барабану, и даже более того - для оператора лучше чтобы в консоль писал сам код команды, потому что если она выполняется долго, то сможет выводить диагностические сообщения. Что ещё я должен был понять из темы "hw на канторе"?

Цитата:
Человеку приятно получать результат путем одного нажатия.


Не соглашусь ещё раз, т.к. в отсутствие графического интерфейса приходится запоминать кучу шорткатов, а это напряжно (http://dkhramov.dp.ua/uploads/Comp/Emacs4CPP/its-emacs.png). Проще помнить имена команд. Их же проще и набирать. Даже если есть графический интерфейс, возюкание мышкой медленнее чем ввод команды с клавиатуры. Хотя это не исключает назначение некоторых часто используемых команд на горячие клавиши. С другой стороны обычно команды идут с параметрами, так что непонятно как вообще можно одним нажатием что то сделать.

Или речь о чём то другом?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 10 май 2015, 13:05 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 241
Откуда: Санкт-Петербург
dragon писал(а):
Меня интересует, что нахлобучить сверху, чтобы оператор чувствовал себя как рыба в воде. Причём тонкость в том, что ZUI и прочие навороты, они уже слишком сложны для реализации

Поиграйся с GW-BASIC, например. Или вспомни, как там было, если уже знаком.

_________________
Путь успеха Циолковского — правильно умереть


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 10 май 2015, 14:17 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Цитата:
GW-BASIC

Определённо то, что нужно. Правда без современных фич типа автодополнения. Пойду подумаю над этим.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 19 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


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

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


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

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB