Здравствуйте, Real 3L0, Вы писали:
0>>Потому, что эти "кубики" не устраняли главной сложности в программировании, они решали не ту проблему. R3>А какую проблему они решали?
На сегодняшних вполне привычных языках количество сущностей в коде можно уменьшить в разы. Но почему-то об этом ни книжек не пишут, ни дискуссий не ведут, тратя вместо этого кучу сил и ресурсов на поиски кубиков, макросов и прочего синтаксического сахара, который все должен упростить. Но ничего кардинально не упрощается, т.к. синтаксический сахар количество сущностей уменьшить не способен.
Здравствуйте, hardcase, Вы писали:
H>Это потому что в электронике зачастую решаются типовые задачи.
Так было не всегда, ещё не так давно электроника была "искусством создания схем", но со временем были определены топовые задачи и типовые решения для них. Думаю тоже сейчас происходит с программированием.
H>Как только появляются нестандартные задачи, в дело идут микроконтроллеры а, в тяжелых случаях — ПЛИСы и DSP, а это уже набивание текста и программизм в полный рост.
Truth.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, Undying, Вы писали:
U>На сегодняшних вполне привычных языках количество сущностей в коде можно уменьшить в разы. Но почему-то об этом ни книжек не пишут, ни дискуссий не ведут, тратя вместо этого кучу сил и ресурсов на поиски кубиков, макросов и прочего синтаксического сахара, который все должен упростить. Но ничего кардинально не упрощается, т.к. синтаксический сахар количество сущностей уменьшить не способен.
Как по вашему это можно добиться значительного уменьшения "количества сучностей"(кроме ручной опитимизации)?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
U>>На сегодняшних вполне привычных языках количество сущностей в коде можно уменьшить в разы. Но почему-то об этом ни книжек не пишут, ни дискуссий не ведут, тратя вместо этого кучу сил и ресурсов на поиски кубиков, макросов и прочего синтаксического сахара, который все должен упростить. Но ничего кардинально не упрощается, т.к. синтаксический сахар количество сущностей уменьшить не способен. AC>Как по вашему это можно добиться значительного уменьшения "количества сущностей"(кроме ручной опитимизации)?
Не понял, каким образом ручной оптимизацией можно уменьшить количество сущностей?
Методов уменьшения количества сущностей достаточно много. Самый крутой из них это построение логики на геттерах, а не на сеттерах, т.е. замена явных присвоений значений по событию на вычисление значений на лету (напрямую или через автоматический кэш) при обращении к этому значению.
Здравствуйте, Undying, Вы писали:
U>Не понял, каким образом ручной оптимизацией можно уменьшить количество сущностей?
А, понял, я мел ввиду то лишнее что остаётся в "сырых" версиях кода.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
R3>Ни в коем случае. Надо будет обязательно использовать существующие наработки. При наличии кода — это не должно быть проблемой. R3>Например, существующий кубик "Блокнот" можно разложить на несколько мелких кубиков, в том числе "Вырезать", "Скопировать" или "Вставить".
а в ворде это будут свои кубики "вырезать", "Скопировать" или "вставить"?
в браузере опять такие же, но свои?
в граф. редакторе тоже?
в файл менеджере?
и т.д?
вот и пошла комбинаторика: кол-во программ * (вырезать, скопировать, вставить)
Здравствуйте, Undying, Вы писали:
U>Главная проблема программирования это большое количество сущностей. Но об этом мало кто задумывается, ломая копья по поводу синтаксиса. Хотя замена синтаксиса на другой это обычно "те же яйца — вид сбоку" вместо упрощения.
А что следует из "большого колличества сущностей"? (Про синтаксис согласен.)
U> Но ничего кардинально не упрощается, т.к. синтаксический сахар количество сущностей уменьшить не способен.
foreach, using, linq, var и т.д. — это всё как раз уменьшение кол-ва сущностей, и это синтаксический сахар
зы
опять же надо понимать что такое уменьшение кол-ва сущностей.
самое минимальное кол-во сущностей — это последовательность 0 и 1. но это не то, что хочется, т.к. в этих сущностях мы не сможем ничего толкового запрограммировать и будем, как минимум, в мозгу выдумать какие-то вспомогательные сущности.
т.е. стоит считать все сущности и те, которые в коде есть, и те которые используются для написания, модифицирования, доказательства правильности и объяснения данного кода
Здравствуйте, Undying, Вы писали:
U>Методов уменьшения количества сущностей достаточно много. Самый крутой из них это построение логики на геттерах, а не на сеттерах, т.е. замена явных присвоений значений по событию на вычисление значений на лету (напрямую или через автоматический кэш) при обращении к этому значению.
Хм, уточни, плиз.
Как я думаю сделать: кубик 1 запрашивает данные А, система смотрит, кто может предоставить данные А — это кубик 2, выполняет кубик 2 — получаем данные А, отдаём данные А кубику 1. Т.е. для получения данных мне всё равно нужна сущность — кубик 2. Как в этом случае должна исчезнуть одна сущность?
Или это как с примером про чтение почты: кубик 1 запросил почту, кубик 2 предоставил почту, что в итоге даёт нам, что кубику 1 не надо знать о существовании сущности "MIME"?
Здравствуйте, DarkGray, Вы писали:
R3>>Например, существующий кубик "Блокнот" можно разложить на несколько мелких кубиков, в том числе "Вырезать", "Скопировать" или "Вставить". DG>а в ворде это будут свои кубики "вырезать", "Скопировать" или "вставить"?
Конечно, нет.
DG>вот и пошла комбинаторика: кол-во программ * (вырезать, скопировать, вставить)
Есть некоторые ограничения, типа различия между функциями "вырезать" у блокнота и у ворда, которые не позволяют тупо объединить все функции "вырезать" в одну. Но эти ограничения — не полная невозможность.
Здравствуйте, DarkGray, Вы писали:
R3>>Например, существующий кубик "Блокнот" можно разложить на несколько мелких кубиков, в том числе "Вырезать", "Скопировать" или "Вставить". DG>а в ворде это будут свои кубики "вырезать", "Скопировать" или "вставить"?
Именно к этой идее меня подтолкнул Джеф Раскин "Интерфейс" — я всё боялся её себе в слух сказать — слишком фантастично она меняла существующий мир: мир без приложений, но с функциями этих приложений.
R3>Именно к этой идее меня подтолкнул Джеф Раскин "Интерфейс" — я всё боялся её себе в слух сказать — слишком фантастично она меняла существующий мир: мир без приложений, но с функциями этих приложений.
именно эта идея и требует, чтобы можно было взять, например, команду "Вырезать" из блокнота, модифицировать ее и применить к ворду, и это тогда позволить что будет одна команда вырезать на все приложения, что позволяет избежать комбинаторного взрыва
Здравствуйте, DarkGray, Вы писали:
DG>именно эта идея и требует, чтобы можно было взять, например, команду "Вырезать" из блокнота, модифицировать ее и применить к ворду, и это тогда позволить что будет одна команда вырезать на все приложения, что позволяет избежать комбинаторного взрыва
Этого требования я у него не заметил.
Попровь меня дальше, если ошибаюсь.
Итак, что мы имеем: блокнот и ворд. Оба приложения — с функцией "вырезать".
Одним из отличий этих команд является то, что ворд понимает формат вырезанного текста. Блокнот — нет, т.к. блокнот работает с голым текстом. (Если вдруг это уже не так, то допустим, что это так. )
Если ворд модифицирует функцию "вырезать" и теперь она понимает формат текста, то блокнот никто модифицировать не будет. Следовательно, чтобы ворд мог отдать текст блокноту, он должен сделать обратное преобразование текста — удалить из текста форматирование. Вроде всё нормально.
Но тут появляется новый игрок: Writer, который понимает форматированный текст по своему и, следовательно, имеет свою функцию "вырезать". И если обмен текстом с блокнотом у него проблем не вызывает, то обмениваться текстом с вордом он не может по причине того, что ворд ни кому не говорит, в каком виде он ожидает принять форматированный текст.
Также, думаю, мы оба знаем, что произойдёт с текстом, при приобразовании "writer — блокнот — ворд".
Несыковка приложений. Такой мир мне не нужен.
Добавлю, что для пользователя ворда, все функции, работающие с неформатированным текстом, станут недоступны для форматированного (вордовского) текста.
Так что такой мир не нужен не только мне, но и этим пользователям. И, следовательно, Раскин не хотел такой функциональности.
R3> И если обмен текстом с блокнотом у него проблем не вызывает, то обмениваться текстом с вордом он не может по причине того, что ворд ни кому не говорит, в каком виде он ожидает принять форматированный текст.
R3>Добавлю, что для пользователя ворда, все функции, работающие с неформатированным текстом, станут недоступны для форматированного (вордовского) текста. R3>Так что такой мир не нужен не только мне, но и этим пользователям. И, следовательно, Раскин не хотел такой функциональности.
это один из пунктов из памятки "Как эффективно передергивать в дискуссии":
припишите утверждение оппоненту или его позиции — а потом доблестно это утверждение разгромите...
ps
и это кстати показывает, что ты не знаешь на каких принципах работает copy/paste в современной ОС.
Здравствуйте, DarkGray, Вы писали:
DG>это один из пунктов из памятки "Как эффективно передергивать в дискуссии": DG>припишите утверждение оппоненту или его позиции — а потом доблестно это утверждение разгромите...
Не понимаю, о каком "передёргивании" идёт речь. Я сюда не для этого пришёл.
Раскин хотел А. Ты пишешь, что для реализации А, надо Б. Я написал, что сделав Б, мы не сможем сделать А, но Раскин хотел А.
DG>и это кстати показывает, что ты не знаешь на каких принципах работает copy/paste в современной ОС.
Возможно, не спорю. Я приводил пример. Аналогичных примеров в современном ПО — тысячи.
Здравствуйте, DarkGray, Вы писали:
DG>foreach, using, linq, var и т.д. — это всё как раз уменьшение кол-ва сущностей, и это синтаксический сахар
Вообще всё в языках программирования — синтаксический сахар. В некотором смысле.
Вот, к примеру, рассмотрим концепцию "вызов функции" в традиционной архитектуре. Предположим, сахара у нас нет.
Это будет что-то типа
— положить параметры в стек, один за другим
— выполнить инструкцию call на адрес функции
— прочитать результат со стека
— очистить стек от параметров, которые мы использовали.
Можно заметить, что это довольно много работы для банального вызова. Давайте внесём в язык синтаксическое соглашение о том, что если мы пишем a = func(b, c), то это означает как раз
— положить в стек c
— положить в стек b
— сделать call на адрес func
— прочитать результат со стека (и положить его в a)
— очистить стек от c и b
Как видим, мы убрали количество сущностей, с которыми программисту нужно оперировать при каждом вызове, введя удобную абстракцию.
Или вот, более современный пример. Есть у нас, допустим, некоторый паттерн — детерминистическая финализация.
Устроенный как-то так:
— берём объект o, реализующий интерфейс IDisposable
— выполняем некоторый код
— в конце блока кода, независимо от того, вылетело исключение или нет, мы проверяем наш объект на != null и в случае успеха вызываем у него IDisposable.Dispose()
Как видим, нам нужно ковыряться в некотором количестве деталей, которые сами по себе не очень нужны. Поэтому можно внести в язык синтаксическую конструкцию using(), которая позволит всем этим не затрудняться, сокращая количество сущностей — и риск совершить ошибку.
И так — весь синтаксис.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Real 3L0, Вы писали:
Z>>Неудачный пример, исходники можно все же скомпилировать и получить программу. Модель скомпилировать нельзя, там явно недостаточно информации. Как только начинается попытка довести ее до достаточной на реальных задачах — все оказывается плачевно. Для каждого кубика приходится писать кучу кода, который читать и поддерживать гораздо сложнее чем те исходники.
R3>Это потому, что нет хорошего конструктора кубиков (КК). Ты описываешь проблемы, присутствующие в существующих КК. Но почему они должны быть в будущих (ещё не созданных) КК?
Процессы либо укладываются в пару-тройку кнопок, из которых составлять кубик бессмысленно, либо различаются в различных деталях, которые вынести в настройки кубика я могу, но вряд-ли кто-то еще сможет ими воспользоваться. Прекрасный пример кубиков это шелл. Именно потому, что конструирование происходит в тексте.
R3>Библиотека — это и есть кубик, но в мире программирования. Либо пишешь код руками (без КК; узнавая, что такое MIME), либо используешь библиотеку (с КК; не узнавая, что такое MIME). Так что нормальный пример.
Ну да. И такие кубики себя прекрасно зарекомендовали. А вот графические конструкторы все как один убоги.
Здравствуйте, DarkGray, Вы писали:
U>> Но ничего кардинально не упрощается, т.к. синтаксический сахар количество сущностей уменьшить не способен. DG>foreach, using, linq, var и т.д. — это всё как раз уменьшение кол-ва сущностей, и это синтаксический сахар
Все перечисленное не уменьшает количество сущностей, а лишь делает их неявными или немного другими. Foreach явное инкрементирование индекса и обращение по нему заменяет на неявный переход на следующий элемент, using явный вызов Dispose в finally заменяет на неявный и т.д.
Для сравнения. Если мы решаем задачу в сеттерном стиле, то при каждом изменении объекта нужно явно оповестить все объекты зависящие от него. Модифицироваться объект может из десятков и сотен мест. Если задача решается в геттерном стиле, то вместо этих вызовов в десятках и сотнях мест будет несколько автоматических кэшей. Соответственно при использовании геттерного стиля из программы исчезают (а не становятся неявными) десятки и сотни сущностей.
Другой пример. В шарпе сделали, что способ передачи переменной (по ссылке или по значению) задается при декларации типа. Тип мы задаем один раз, переменные этого типа может передавать сотни и тысячи раз. Соответственно благодаря этому из программы исчезают сотни и тысячи сущностей.
Вот поэтому геттерный стиль и определение способа передачи объекта на уровне типа это решения позволяющие кардинально снизить сложность программирования. А все тобой перечисленное это унылый синтаксический сахар, который либо снижает сложность программирования незначительно (foreach, using), либо и вовсе сложность не уменьшает (linq, var). Соответственно, если из шарпа выкинуть все тобой перечисленное, то моя прозводительность снизится на 1%, а число ошибок увеличится еще менее, а если я буду писать в сеттерном стиле вместо геттерного, то производительность упадет в разы, а число ошибок возрастет на порядок.
DG>самое минимальное кол-во сущностей — это последовательность 0 и 1. но это не то, что хочется, т.к. в этих сущностях мы не сможем ничего толкового запрограммировать и будем, как минимум, в мозгу выдумать какие-то вспомогательные сущности.
Ты путаешь количество сущностей в языке и количество сущностей в программе. Стремиться надо ко второму, а не к первому.
