Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, gandjustas, Вы писали:
G>>>>Дык уже есть. Бери 1с, Dynamics, SharePoint. Там ты не пишешь приложение, там ты создаешь объекты, описываешь действия, и представления результатов. R3>>>Ну и как "ложится" вышеприведённый пример с принтером в эти системы? G>>Создаешь объект "принтер", прописываешь ему свойства, задаешь действие — печатать, которое может спросить файл например.
R3>А после этих действий, упомянутый тобой объект "файл" будет знать, что теперь его можно печатать? Или надо дополнительно какие-то связи прописывать?
Как ты сделаешь — так и будет. Придумай реальную задачу, а не сфероконя_в_вакууме.
Здравствуйте, gandjustas, Вы писали:
G>Как ты сделаешь — так и будет.
Т.е. если у меня в базе милион разных объектов, то мне это для каждого надо будет делать? Не интересно.
G> Придумай реальную задачу, а не сфероконя_в_вакууме.
Это самая что ни на есть реальная задача. Не все пользователи компьютеров считают бюджеты и проводят платёжки.
U>Логически у нас есть задачи: прервать выполнение с ошибкой и освободить ресурсы после того как объект стал ненужен. Эти логические задачи и решает то, что ты перечислил, скрывая от нас механику решения, которая с логической точки зрения является мусором.
DG>>и какую бизнес-сущность описывает, например, операция foreach или while?
U>Логически у нас есть задачи: выполнить для каждого элемента и повторить. Эти логические задачи решаются в шарпе с помощью foreach и while.
DG>>перечисли, пожалуйста, хотя бы штук 30 таких логических сущностей, которые скрывать не стоит, чтобы понятно было о чем речь
U>Это сущности, которые заметны или могут быть заметны для пользователя (уточню, что пользователем может быть не только человек, но и программное окружение).
если использовать это определение, то с точки зрения пользователя все наоборот:
1. с точки зрения пользователя важно какой будет путь ошибки, что будет прервано, а что не будет, а текущие exception-ы это скрывают. например, при копировании файлов при ошибках будут отменено копирование последующих файлов, или не будет?
2. с точки зрения пользователя нет "операции для каждого элемента", а уж тем более "повторить". похожи хоть один интерфейс где эти операции есть? но есть операции — для всех, для выбранных, отфильтровать, найти и т.д.
зы
и убери из критерия слово "программное окружение", а то я могу привести кучу программных окружений для которых важно размещение по памяти(например, вирусы), или важно размещение по регистрам (например, числомолотилки для которых важен каждый процент скорости)
R3>Я к тому, что наши процессы (бизнес-процессы, процессы жизнидеятельности) уже описаны или могут быть описаны. Но мы этим не пользуемся в полной мере.
потому что мы не умеем описывать мир.
если использовать имеющиеся инструменты, то вот здесь как раз комбинаторный взрыв и происходит.
R3>Почему программист не может просто, например, поставить где-то пару галочек: "форма имеет кнопку закрытия с сохранением ввода" и "форма имеет кнопку закрытия с отклонением ввода", а всё остальное будет сделано автоматически?
и сколько таких галочек будет? 5, 10, 100, 100000, миллион?
тут же как получается, если мы хотим сохранить ту же самую мощность выбора, то кол-во галочек должно быть равным кол-ву исходных вариантов, а если начинаем уменьшать галочки, то получаем куцый инструмент который мало что умеет.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, gandjustas, Вы писали:
G>>Как ты сделаешь — так и будет.
R3>Т.е. если у меня в базе милион разных объектов, то мне это для каждого надо будет делать? Не интересно.
Миллион разных это как? По структуре или по значениям атрибутов?
Первое — не поверю, второе — в чем проблема?
G>> Придумай реальную задачу, а не сфероконя_в_вакууме. R3>Это самая что ни на есть реальная задача. Не все пользователи компьютеров считают бюджеты и проводят платёжки.
Еще меньше считают что "принтер" это объект. Для большинства людей печать — это функция, объекты тут не при чем.
Здравствуйте, DarkGray, Вы писали:
DG>потому что мы не умеем описывать мир. DG> если использовать имеющиеся инструменты, то вот здесь как раз комбинаторный взрыв и происходит.
Умеем. Я неоднократно описывал.
Правда, конечно, не весь мир. И не очень детально. (Хотя углубиться в детали — не проблема.)
Но все были довольны.
R3>>Почему программист не может просто, например, поставить где-то пару галочек: "форма имеет кнопку закрытия с сохранением ввода" и "форма имеет кнопку закрытия с отклонением ввода", а всё остальное будет сделано автоматически? DG>и сколько таких галочек будет? 5, 10, 100, 100000, миллион?
Ну, вот сейчас, можно сказать, уже есть намёки на эти галочки: в студии, на форме, если она имеет кнопки, можно выбрать, какая кнопка ОК, а какая — Cancel.
Т.е. получается, что часто используемые варианты машина может "обдумать" сама, а что-то более сложное — отдаётся на реализацию программисту.
DG>тут же как получается, если мы хотим сохранить ту же самую мощность выбора, то кол-во галочек должно быть равным кол-ву исходных вариантов, а если начинаем уменьшать галочки, то получаем куцый инструмент который мало что умеет.
Ты недопонял мой текст, который шел после галочек.
Смысл в том, что когда однотипных сущностей становится много — их объеденяют в группы. Пользователь начинает управлять группами сущностей, а компьютер получает навык управления единичными сущностями.
Когда становится много групп сущностей — пользователь переходит ещё выше на уровень. И т.д.
Но, конечно, повышения уровня не произойдёт, пока компьютер не научат управлять предыдущим уровнем.
Здравствуйте, gandjustas, Вы писали:
G>Миллион разных это как? По структуре или по значениям атрибутов? G>Первое — не поверю, второе — в чем проблема?
По структуре. Т.е. ты не веришь, что на свете существует миллион различных объектов (правильнее — классов, если объект — это экземпляр класса)? Открой, например, википедию.
R3>>Это самая что ни на есть реальная задача. Не все пользователи компьютеров считают бюджеты и проводят платёжки. G>Еще меньше считают что "принтер" это объект. Для большинства людей печать — это функция, объекты тут не при чем.
Я не говорил, что пользователь считает "принтер" чем-то там. Я про печать и говорил, но ты посчитал это "сфероконём_в_вакууме".
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, gandjustas, Вы писали:
G>>Миллион разных это как? По структуре или по значениям атрибутов? G>>Первое — не поверю, второе — в чем проблема?
R3>По структуре. Т.е. ты не веришь, что на свете существует миллион различных объектов (правильнее — классов, если объект — это экземпляр класса)? Открой, например, википедию.
А причем тут объекты существующие на свете? Главное какие объекты в программе. Я вот совершенно не верю что в программе будет миллион или даже тысяча разных объектов.
R3>>>Это самая что ни на есть реальная задача. Не все пользователи компьютеров считают бюджеты и проводят платёжки. G>>Еще меньше считают что "принтер" это объект. Для большинства людей печать — это функция, объекты тут не при чем.
R3>Я не говорил, что пользователь считает "принтер" чем-то там. Я про печать и говорил, но ты посчитал это "сфероконём_в_вакууме".
R3>Ну и как "ложится" вышеприведённый пример с принтером в эти системы?
Здравствуйте, jazzer, Вы писали:
J>Да ладно. COM + VB — отличный кубики, все очень легко и просто. J>Или Дельфи с ее компонентами. J>Кубики писать — да, геморрой, а из имеющихся кубиков все очень легко собирается.
Вот чтобы кубиками можно было эффективно пользоваться и нужно метапрограммирование.
Потому что кубики, имеющиеся в наличии и те что нужны в конкретном случае, не перекрываются полностью, а только частично пересекаются. Либо будет чего-то не хватать, либо будет что-то лишнее. Если бы метапрограммы вырезали лишнее, уже было бы не плохо (вырезать легче чем дописывать). Лишнее это не просто лишние мертвые функции, которые ни разу не вызываются.
Многими хорошими приемами программирования пользуются мало потому что слишком большой оверхед (например реактивное програмирование). Оверхед довольно тупой, метапрограмме его по силам удалить.
Здравствуйте, gandjustas, Вы писали:
R3>>По структуре. Т.е. ты не веришь, что на свете существует миллион различных объектов (правильнее — классов, если объект — это экземпляр класса)? Открой, например, википедию. G>А причем тут объекты существующие на свете? Главное какие объекты в программе. Я вот совершенно не верю что в программе будет миллион или даже тысяча разных объектов.
Потому что эти объекты реально существуют. Сейчас — (максимум) в разных программах.
А при наличии связей между объектами можно получить некоторые автоматически генерируемые вещи. Тогда наличие миллиона объектов нам не страшно.
При отсутствии же связей (что мы сейчас и видим) — каждый разработчик делает либо велосипед (клон, т.е. уже кто-то это делал), либо не связаную с другими вещь.
R3>>>>Это самая что ни на есть реальная задача. Не все пользователи компьютеров считают бюджеты и проводят платёжки. G>>>Еще меньше считают что "принтер" это объект. Для большинства людей печать — это функция, объекты тут не при чем.
R3>>Я не говорил, что пользователь считает "принтер" чем-то там. Я про печать и говорил, но ты посчитал это "сфероконём_в_вакууме". G>
R3>>Ну и как "ложится" вышеприведённый пример с принтером в эти системы?
G>Не выкручивайся.
Так ты начни с самого начала:
Пример команды с принтером:
... надо напечатать документ. Ты говорил, что количество уточняющих деталей (например, какой именно принтер или как именно надо напечатать) не позволит легко пользоваться такими командами.
и далее по ветке всё, что касается этого примера с принтером.
Здравствуйте, DarkGray, Вы писали:
U>>Это сущности, которые заметны или могут быть заметны для пользователя (уточню, что пользователем может быть не только человек, но и программное окружение).
DG>если использовать это определение, то с точки зрения пользователя все наоборот: DG>1. с точки зрения пользователя важно какой будет путь ошибки, что будет прервано, а что не будет, а текущие exception-ы это скрывают. например, при копировании файлов при ошибках будут отменено копирование последующих файлов, или не будет?
В каком месте реализация обработки исключений, к примеру, в шарпе ограничивает возможности программиста по прерыванию операции в нужный момент или, наоборот, глушению ошибки?
DG>2. с точки зрения пользователя нет "операции для каждого элемента", а уж тем более "повторить". похожи хоть один интерфейс где эти операции есть? но есть операции — для всех, для выбранных, отфильтровать, найти и т.д.
Если начать детализировать пользовательские операции, то там тут же окажутся операции — и для каждого элемента, и повторить. И никуда от них не дется, т.к. эти операции диктуются логикой задач. А вот никаких регистров в логическом алгоритме нет, поэтому от них можно и нужно избавляться в коде.
DG>зы DG>и убери из критерия слово "программное окружение", а то я могу привести кучу программных окружений для которых важно размещение по памяти(например, вирусы), или важно размещение по регистрам (например, числомолотилки для которых важен каждый процент скорости)
Вирусы и числомолотилки пишут на шарпе? Я же писал:
Поэтому скрывать аппаратные сущности можно и нужно. При условии, конечно, что это не приводит к критической просадке производительности на том классе задач, для решения которых предназначен язык/библиотека.
Здравствуйте, DarkGray, Вы писали:
S_S>> (вырезать легче чем дописывать) DG>но сложнее это сделать без ошибок
Это програмисту приходится ошибки совершать. А метапрограма либо справится с преобразованием, либо нет, ошибку не сделает.
Например, кто-то написал некий класс ObservableCollection<T> , который при изменениях коллекции составляет списки измененных элементов, и отсылает их через события(колбэки).
Кто-то допустим подключил к нему обработчик только устанавливающий флажок changed=true.
Дальше флажок сбрасывается, вызывается код который вносит кучу изменений в колекцию, по окончанию флажок считывается.
Тут куча лишнего будет делаться, если обработчик не использует параметры:
— составляются списки измененных элементов, отправляются в обработчик а в нем игнорируются. Код составляющий эти списки можно выкинуть.
— за время исполнения куска кода флажок не читается а много раз перезаписывается — предыдущий вычесленный результат отбрасывается. Установку флажка можно вынести за цикл и сделать один раз.
Эти переделки программы не такие уж сложные, не требуется какой-то супер-компилятор который умеет все.
Где-то "в песочнице" на упрощенном языке, где нет Reflection и прочих сложностей, такое переписывание сделать не сложно — удаление кода результаты выполнения которого отбрасываются (игнорируются или перезаписываются без чтения). Кэширование и снятие лишних косвенностей тоже сюда входит.
U>В каком месте реализация обработки исключений, к примеру, в шарпе ограничивает возможности программиста по прерыванию операции в нужный момент или, наоборот, глушению ошибки?
как минимум в отсутствии вариационности по: пропускать ошибку/падать по ошибке и т.д.
т.е. очень сложно написать значительный по объему код, который в качестве параметра принимал бы настройку как действовать по ошибке:
падать сразу,
игнорировать,
накапливать ошибки, а потом падать,
накапливать в виде warning-ов,
повторить операцию пару раз, а потом падать
и т.д.
а все это желательно на такой простой задаче, как, например, брауз директорий, а так же на любой задаче которая взаимодействует с недружелюбным миром
S_S> А метапрограма либо справится с преобразованием, либо нет, ошибку не сделает.
даже метапрограмме проще что-то собирать из кусочков, чем кусочки отпиливать от чего-то существующего.
отпиливать тяжело тем, что очень тяжело аккуратно отпилить также все следствия отпиливаемого.
зы
ты может быть говоришь про случай, когда система спроектирована под конкретные отпилы, и именно эти отпилы и используются — тогда проблем нет, но это частный случай.
S_S>такое переписывание сделать не сложно — удаление кода результаты выполнения которого отбрасываются
это подразумевает, что в коде прописано всё знание, которое имел программист.
обычно это не так, и в код прописывается лишь пара процентов знаний о задаче, остальное используется неявно.
например, в программу не прописывают почему взят именно int: а не short, long или biginteger?
также в программу не прописывается почему взят этот алгоритм, а не другой?
последовательность обратывается последовательно, что это действительно так необходимо, или потому что программисту не было необходимости писать параллельную обработку?
и т.д.
Здравствуйте, DarkGray, Вы писали:
DG>как минимум в отсутствии вариационности по: пропускать ошибку/падать по ошибке и т.д. DG>т.е. очень сложно написать значительный по объему код, который в качестве параметра принимал бы настройку как действовать по ошибке: DG>падать сразу, DG>игнорировать, DG>накапливать ошибки, а потом падать, DG>накапливать в виде warning-ов, DG>повторить операцию пару раз, а потом падать DG> и т.д.
Не понял в чем проблема.
class ExceptionWorker
{
ExceptionSettings settings;
public void Execute(Action action);
}
В зависимости от настроек обрабатываешь ошибку нужным образом и повторяешь действие если нужно.
DG>а все это желательно на такой простой задаче, как, например, брауз директорий, а так же на любой задаче которая взаимодействует с недружелюбным миром
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, gandjustas, Вы писали:
R3>>>По структуре. Т.е. ты не веришь, что на свете существует миллион различных объектов (правильнее — классов, если объект — это экземпляр класса)? Открой, например, википедию. G>>А причем тут объекты существующие на свете? Главное какие объекты в программе. Я вот совершенно не верю что в программе будет миллион или даже тысяча разных объектов.
R3>Потому что эти объекты реально существуют. Сейчас — (максимум) в разных программах.
И что?
R3>А при наличии связей между объектами можно получить некоторые автоматически генерируемые вещи. Тогда наличие миллиона объектов нам не страшно.
Надо задать как сами объекты, так и связи. Количество связей это примерно N^2.
Физически это невозможно.
Но есть еще и пользователи, которые хотят работать им миллионы не нужны, им нужно гораздо меньше. Так что такое кол-во и не нужно.
Здравствуйте, gandjustas, Вы писали:
R3>>Потому что эти объекты реально существуют. Сейчас — (максимум) в разных программах. G>И что?
То, что ими пользуются.
R3>>А при наличии связей между объектами можно получить некоторые автоматически генерируемые вещи. Тогда наличие миллиона объектов нам не страшно. G>Надо задать как сами объекты, так и связи. Количество связей это примерно N^2. G>Физически это невозможно.
Если есть автоматика, то возможно.
G>Но есть еще и пользователи, которые хотят работать им миллионы не нужны, им нужно гораздо меньше. Так что такое кол-во и не нужно.
Вообще-то, то, про что я говорю, как раз и направлено на уменьшение количества объектов (сущностей).
Предложенные тобой системы наоборот — увеличивают количество объектов.
На примере это выглядит так:
Есть какой-нибудь мессенджер, который предоставляет пользователям обмен текстовыми сообщениями. Возникает необходимость в функциональности голосовой связи. Сейчас либо пишут новый мессенджер (повторно реализуя функционал обмена текстовыми сообщениями), либо присобачивают новую функциональность к существующему так, что лучше они бы этого не делали. Потому что голосовая связь — это тоже сообщения, только другого типа, но она также как и текстовые сообщения должна передавать некоторую информацию в "основную базу" мессенджера, например, время отправки сообщения и т.п.
Т.е. в результате мы либо получаем два мессенджера, что даёт нам один лишний функционал (текстовые сообщения), либо мессенджер будет один, но новый функционал будет плохо коррелировать с сущенствующим.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, gandjustas, Вы писали:
R3>>>Потому что эти объекты реально существуют. Сейчас — (максимум) в разных программах. G>>И что?
R3>То, что ими пользуются.
Всеми сразу в одной программе? Снова не верю.
R3>>>А при наличии связей между объектами можно получить некоторые автоматически генерируемые вещи. Тогда наличие миллиона объектов нам не страшно. G>>Надо задать как сами объекты, так и связи. Количество связей это примерно N^2. G>>Физически это невозможно.
R3>Если есть автоматика, то возможно.
Какая автоматика? Что может избавить от описания объектов?
Мало того что компьютер не знает о "реальном мире", так и еще любой срез атрибутов "реального мира" будет или избыточен или недостаточен для конкретной задачи. Поэтому даже если бы автоматика существовала, то все равно необхдимость описывать руками никуда бы не делась.
R3>Предложенные тобой системы наоборот — увеличивают количество объектов.
Счегобы?
R3>На примере это выглядит так: R3>Есть какой-нибудь мессенджер, который предоставляет пользователям обмен текстовыми сообщениями. Возникает необходимость в функциональности голосовой связи. Сейчас либо пишут новый мессенджер (повторно реализуя функционал обмена текстовыми сообщениями), либо присобачивают новую функциональность к существующему так, что лучше они бы этого не делали. Потому что голосовая связь — это тоже сообщения, только другого типа, но она также как и текстовые сообщения должна передавать некоторую информацию в "основную базу" мессенджера, например, время отправки сообщения и т.п.
Есть скайп, Lync и другие сервисы. Писать не надо. Кроме того ты опять путаешь объекты и функции. Я говорю про описание объектов, ты говоришь зачем-то о функциях передачи сообщений и голоса. Если пытаться декомпозировать задачу передачи сообщений, то мы совсем уйдем от "реального мира" и бизнес-задач.
Я неоднократно описывал. 
