Здравствуйте, Real 3L0, Вы писали:
R3>Сейчас не нужны, и потом не будут нужны. Кому нужен второй кубик, если есть первый, делающий тоже самое?
Напоминаю, мы говорим о замене для
var customer = customers.Where(c => c.Age > 18 && c.NotBanned).Skip(123).FirstOrDefault();
Допустим, завтра мне потребуется добавить пару условий, послезавтра — брать последнего найденного кастомера, через месяц — считать статистику по неподпавшим под условие. Где вы наберёте кубиков для всего?
R3>Это было всего лишь моё предположение. R3>Но всё равно не надо думать, что тачскрин на больших экранах не нужен совсем.
Как основной способ управления — не нужен. Но давайте вернёмся к теме
S>>Ни в одном онлайн-каталоге её не решили. И решать не будут, т.к. это требует привлечения на порядок больших расходов и только мешает основной цели существования сайа — продать/привлечь побольше посетителей. R3>И расходы нужны не большие. По крайней мере в моём решении этой проблемы. Но да — "привлечение" у меня страдает.
Неа. Рецепты из серии "пчёлы против мёда" в жизни нифига не работают.
R3>>>Эээ, с чего это? Ты сопровождаешь только свой кубик. S>>Неа, раз уж взялся лезть во внутренности чужого кода — будь добр сам нести ответственность за последствия. R3>Чужой код и замена одного кубика — это разные вещи.
Не замена, а попытка вломиться в чужой код для добавления неподдерживаемых фич. Это оччень разные вещи.
Вообще все эти переливания из пустого в порожнее не имеют за собой никакой практической ценности. Пока вы не представите свое видение всей потребной инфраструктуры для массового и распределённого производства совместимых всемогуторов, мы так и будем перекидываться доводами "взлетит-не взлетит", "тачпады тоже нужны" и байками про простоту расширения чужого кода. Я таки самоустранюсь, вам — удачи и спасибо за приятный спор
с кубиками всё упирается в то, что:
1. не проработан вопрос модификации готового кубика
2. не проработан вопрос наследования одного кубика от другого
например, от кубика со структурой дом->квартира в текущих средах разработки почти невозможно перейти к кубику со структурой дом->подъезд->квартира или дом->этаж->квартира, не говоря уже о структуре дом->подъезд,этаж->квартира
S>Допустим, завтра мне потребуется добавить пару условий, послезавтра — брать последнего найденного кастомера, через месяц — считать статистику по неподпавшим под условие. Где вы наберёте кубиков для всего?
и чем не устраивают кубики:
.Where
.Age
18 >
&&
.NotBanned
.Skip
123
.FirstOrDefault
?
DG>>и чем не устраивают кубики: S>Всем устраивают. олько чем они отличаются от текущего положения дел?
тем что кроме мелких кубиков, нет крупных кубиков.
например,
кубик Where есть, но визуального(пользовательского) Where уже нет
кубик Linq есть, но визуального(пользовательского) Linq нет
и т.д.
Здравствуйте, DarkGray, Вы писали:
DG>тем что кроме мелких кубиков, нет крупных кубиков. DG> кубик Linq есть, но визуального(пользовательского) Linq нет DG>и т.д.
Workflow Foundation?
Проблема в том, что для пользователей вся эта требуха чрезмерно сложна, для программистов — слишком громоздка, вот и остаётся очень узкая ниша конфигурируемых продуктов.
это какой-то другой кубик.
S>Проблема в том, что для пользователей вся эта требуха чрезмерно сложна, для программистов — слишком громоздка, вот и остаётся очень узкая ниша конфигурируемых продуктов.
странная отмазка — особенно о том, что для пользователей — это слишком сложно.
например, в аналитических программах интерфейс еще сложнее, в тех же почтовиках, что bat, что mail.ru, что gmail — фильтры имеют именно такой функционал.
но в тоже время кубика нет, и каждый раз приходится делать велосипед заново.
Здравствуйте, jazzer, Вы писали:
J>>>А то так можно договориться до того, что трудно найти сотрудников, дешевый офис и страну с низкими налогами. R3>>А резве не так? J>Так, конечно, но какое это отношение имеет к языку программирования? Мы же, вроде, о программировании тут говорим
Так я и говорю, что сотрудников ищут не в гугле, а не специализированном сайте. Почему же ты считаешь, что для поиска нужного кубика будет достаточно гугля?
Здравствуйте, Sinix, Вы писали:
S>Допустим, завтра мне потребуется добавить пару условий, послезавтра — брать последнего найденного кастомера, через месяц — считать статистику по неподпавшим под условие. Где вы наберёте кубиков для всего?
Ну, фантазировать можно много. За всю мою карьеру в качестве аналитика, такие мелкие измения в процессах случались ну очень редко.
S>>>Ни в одном онлайн-каталоге её не решили. И решать не будут, т.к. это требует привлечения на порядок больших расходов и только мешает основной цели существования сайа — продать/привлечь побольше посетителей. R3>>И расходы нужны не большие. По крайней мере в моём решении этой проблемы. Но да — "привлечение" у меня страдает. S>Неа. Рецепты из серии "пчёлы против мёда" в жизни нифига не работают.
Ну почему же. Вот яблочники (вроде как) очень сильно следят за качеством программ.
R3>>Чужой код и замена одного кубика — это разные вещи. S>Не замена, а попытка вломиться в чужой код для добавления неподдерживаемых фич. Это оччень разные вещи.
Да с чего ты постоянное в этом примере прилепляешь "чужой код"? Когда ты используешь, например, log4net и у тебя падает приложение, ты первым делом думаешь, что проблема у log4net, или у тебя?
Или ты просто не можешь представить такой технологии, что кубики можно разделить (сделать независимыми между собой)?
S>Вообще все эти переливания из пустого в порожнее не имеют за собой никакой практической ценности. Пока вы не представите свое видение всей потребной инфраструктуры для массового и распределённого производства совместимых всемогуторов, мы так и будем перекидываться доводами "взлетит-не взлетит", "тачпады тоже нужны" и байками про простоту расширения чужого кода. Я таки самоустранюсь, вам — удачи и спасибо за приятный спор
Лучше бы ты помог мне реальным делом. Ну да ладно.
Здравствуйте, DarkGray, Вы писали:
DG>с кубиками всё упирается в то, что: DG>1. не проработан вопрос модификации готового кубика
Кубик, который является только кодом, т.е. не состоит из других кубиков, пусть подифицирует разработчик.
DG>2. не проработан вопрос наследования одного кубика от другого
А зачем нужно наследование кубиков? Взаимодействия не достаточно?
DG>например, от кубика со структурой дом->квартира в текущих средах разработки почти невозможно перейти к кубику со структурой дом->подъезд->квартира или дом->этаж->квартира, не говоря уже о структуре дом->подъезд,этаж->квартира
DG>>1. не проработан вопрос модификации готового кубика
R3>Кубик, который является только кодом, т.е. не состоит из других кубиков, пусть подифицирует разработчик.
не понятно откуда следует что этого достаточно для решения задач
DG>>2. не проработан вопрос наследования одного кубика от другого
R3>А зачем нужно наследование кубиков? Взаимодействия не достаточно?
если ограничиться только взаимодействием, то кубиков требуется бесконечное множество даже для простейших задач
DG>>например, от кубика со структурой дом->квартира в текущих средах разработки почти невозможно перейти к кубику со структурой дом->подъезд->квартира или дом->этаж->квартира, не говоря уже о структуре дом->подъезд,этаж->квартира
есть готовый кубик, который описывает целый дом, при этом он считает, что в дом напрямую "вставлены" квартиры.
например, такая модель достаточно для прописки, задания почтового адреса и т.д.
но, например, для расчета давления воды или для стоимости доставки до квартиры тяжелых грузов — нужно еще понятие Этаж.
и либо необходимо модифицировать уже готовый кубик Дом из предыдущего примера, либо разрабатывать с нуля новый.
Здравствуйте, DarkGray, Вы писали:
R3>>Кубик, который является только кодом, т.е. не состоит из других кубиков, пусть подифицирует разработчик. DG>не понятно откуда следует что этого достаточно для решения задач
Этого достаточно для решения некоторого колличества задач.
DG>>>2. не проработан вопрос наследования одного кубика от другого R3>>А зачем нужно наследование кубиков? Взаимодействия не достаточно? DG>если ограничиться только взаимодействием, то кубиков требуется бесконечное множество даже для простейших задач
Я не понимаю, почему все (кажется, все) используют в таких спорах аргумент, что необходимо решать какое-то бесконечное множество задач.
Современное программное обеспечение не решает бесконечное множество задач, тем не менее, их количества достаточно, для решения большинства задач и пользователи не сильно от этого страдают. В настоящее время они (пользователи) просят, например, от меня, решения опрделённого колличества их задач, но никак не бесконечного колличества.
Что же касается наследования, по-моему (возможно я не прав, ибо не думал в эту сторону), оно ничем не лучше взаимодействия (возможно, хуже).
Наследование: кубик Б наследован от кубика А == мы не можем легко (т.е. "ни о чём не думая") изменить кубик А, не поломав что-то в кубике Б; а также, кубик Б не имеет смысла существования, при отсутствии кубика А.
Взаимодействие: кубик Б взаимодействует с кубиком А, т.е. каждый из этих кубиков обладает полноценной системой, решающей определённое количество задач — кубик Б выполняет свои задачи и сообщает о результате кубику А, не зависимо от наличия кубика А (конечно, всё делается без потери данных).
Может я сейчас скажу неудачный пример, но вот для подсчёта количества объектов в списке, нам нужно знать типы/классы этих объектов, или достаточно знать того, что этого список?
DG>есть готовый кубик, который описывает целый дом, при этом он считает, что в дом напрямую "вставлены" квартиры. DG>например, такая модель достаточно для прописки, задания почтового адреса и т.д. DG>но, например, для расчета давления воды или для стоимости доставки до квартиры тяжелых грузов — нужно еще понятие Этаж. DG>и либо необходимо модифицировать уже готовый кубик Дом из предыдущего примера, либо разрабатывать с нуля новый.
Мне кажется, что ты как раз и показал, в чём заключается проблема наследования.
R3>Этого достаточно для решения некоторого колличества задач.
двух штук?
DG>>>>2. не проработан вопрос наследования одного кубика от другого R3>>>А зачем нужно наследование кубиков? Взаимодействия не достаточно? DG>>если ограничиться только взаимодействием, то кубиков требуется бесконечное множество даже для простейших задач
R3>Я не понимаю, почему все (кажется, все) используют в таких спорах аргумент, что необходимо решать какое-то бесконечное множество задач.
потому что есть такая наука комбинаторика
и она утверждает что даже малое кол-во элементов оперирует огромными числами.
например, такие числа как 12!, 2^20, 10^10 уже бесконечные с точки зрения практики, а они появляются лишь на наборах из 10-20 элементах
посчитай, например, сколькими способами можно вывести строчку, хотя бы в html
посчитай сколько способов не используется
посчитай сколько кубиков для вывода текста необходимо, если кубик для вывода текста не умеет модифицироваться.
R3>Современное программное обеспечение не решает бесконечное множество задач, тем не менее, их количества достаточно, для решения большинства задач и пользователи не сильно от этого страдают. В настоящее время они (пользователи) просят, например, от меня, решения опрделённого колличества их задач, но никак не бесконечного колличества.
это аргумент из разряда: пользователи не должны этого хотеть. и обычно он не работает.
R3>Взаимодействие: кубик Б взаимодействует с кубиком А, т.е. каждый из этих кубиков обладает полноценной системой, решающей определённое количество задач — кубик Б выполняет свои задачи и сообщает о результате кубику А, не зависимо от наличия кубика А (конечно, всё делается без потери данных).
возьми несколько любых задач, и представь что один из кубиков что-то не умеет
а потом попробуй разобрать как ты сможешь эту проблему решить без модификации данного кубика одним лишь взаимодействием.
хотя бы что-нибудь банальное: есть winforms, есть label, а текст надо написать под углом 30 градусов
R3>Может я сейчас скажу неудачный пример, но вот для подсчёта количества объектов в списке, нам нужно знать типы/классы этих объектов, или достаточно знать того, что этого список?
для хорошего решения нам необходимо знать тип списка
например, если список это массив, то достаточно спросить длину и это даст эффективность O(1)
DG>>есть готовый кубик, который описывает целый дом, при этом он считает, что в дом напрямую "вставлены" квартиры. DG>>например, такая модель достаточно для прописки, задания почтового адреса и т.д. DG>>но, например, для расчета давления воды или для стоимости доставки до квартиры тяжелых грузов — нужно еще понятие Этаж. DG>>и либо необходимо модифицировать уже готовый кубик Дом из предыдущего примера, либо разрабатывать с нуля новый.
R3>Мне кажется, что ты как раз и показал, в чём заключается проблема наследования.
а ты что предлагаешь? писать всё заново? а кто за это заплатит?
или ты надеешься что ты господь бог и всеведущий, и заранее все варианты предусмотришь?
Здравствуйте, DarkGray, Вы писали:
R3>>Этого достаточно для решения некоторого колличества задач. DG>двух штук?
Если этого достаточно, значит так оно и есть.
DG>посчитай, например, сколькими способами можно вывести строчку, хотя бы в html
Это задача из разрядка "экзотики". Конечно, если мы начнём удовлетворять пожелания каждого пользователя, то программу надо будет писать под каждого пользователя.
Я говорю о полезных задачах. О бизнес-задачах.
Например, для форматирования флешки я знаю только одну команду: "мой компьютер — диск: — формат". Всё. Никакие бесчётные множества способов форматирования флешки мне не нужны. Да их и не много, на самом деле. И почему-то никакая комбинаторика не использовалась.
И именно из этого я исхожу: постановка задачи — результат.
R3>>Современное программное обеспечение не решает бесконечное множество задач, тем не менее, их количества достаточно, для решения большинства задач и пользователи не сильно от этого страдают. В настоящее время они (пользователи) просят, например, от меня, решения опрделённого колличества их задач, но никак не бесконечного колличества. DG>это аргумент из разряда: пользователи не должны этого хотеть. и обычно он не работает.
Я ни слова не сказал про "не должны хотеть". Ключевое слово в моём абзаце — "конечное колличество".
DG>возьми несколько любых задач, и представь что один из кубиков что-то не умеет
Почти такая же фраза и была у меня в начале. Только звучала она по другому: сделаем кубик, который умеет только что-то одно ...
DG>а потом попробуй разобрать как ты сможешь эту проблему решить без модификации данного кубика одним лишь взаимодействием.
Взял, и тупо (в упор) решил.
Я не хвалюсь, ибо понимаю, что решение с одной стороны просто смешно; а с другой, возможно, не для всех задач это решение сработает. Но для части задач оно подходит просто уникально.
DG>хотя бы что-нибудь банальное: есть winforms, есть label, а текст надо написать под углом 30 градусов
Эта задача, как бы, не решается моей системой. В качестве аналога можно посмотреть https://mozillalabs.com/ubiquity/ У них "команда" запускает "что-то" на выполнение, но сама система ничего не делает.
R3>>Мне кажется, что ты как раз и показал, в чём заключается проблема наследования. DG>а ты что предлагаешь? писать всё заново? а кто за это заплатит?
Ни в коем случае. Надо будет обязательно использовать существующие наработки. При наличии кода — это не должно быть проблемой.
Например, существующий кубик "Блокнот" можно разложить на несколько мелких кубиков, в том числе "Вырезать", "Скопировать" или "Вставить".
DG>или ты надеешься что ты господь бог и всеведущий, и заранее все варианты предусмотришь?
Единственное, на что я надеюсь, это дописать проект. Если сделаю хотя бы часть из того, что я "нафантазировал" и это будет работать так, как мне хотелось бы, то как минимум я буду этим пользоваться. Это реально облегчит мне жизнь. Ну а если это облегчит жизнь кому-то ещё, то вообще здорово.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, jazzer, Вы писали:
J>>>>А то так можно договориться до того, что трудно найти сотрудников, дешевый офис и страну с низкими налогами. R3>>>А резве не так? J>>Так, конечно, но какое это отношение имеет к языку программирования? Мы же, вроде, о программировании тут говорим
R3>Так я и говорю, что сотрудников ищут не в гугле, а не специализированном сайте. Почему же ты считаешь, что для поиска нужного кубика будет достаточно гугля?
Я обобщенный гугль имел в виду, в качестве синонима "интернет с поиском". К языкам все это какое отношение имеет, ты скажешь наконец?
?
Если да, то я сказал, что если нужный кубик под рукой, то всё супер. Если же нет, то ни о какой лёгкости речи быть не может, какой бы язык при этом не использовался.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, jazzer, Вы писали:
J>>... К языкам все это какое отношение имеет, ты скажешь наконец?
R3>Я немножко потерялся — ты про это http://www.rsdn.ru/forum/philosophy/4300001.1.aspx
? R3>Если да, то я сказал, что если нужный кубик под рукой, то всё супер. Если же нет, то ни о какой лёгкости речи быть не может, какой бы язык при этом не использовался.
Ну тогда я не вижу противоречия своим словам, ты говоришь ровно то же, что я сказал там.
Могу привести в качестве примера современную электронику, где решение проблемы, в большинстве случаев, сводится к выбору нужных "кубиков".
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Здравствуйте, Real 3L0 AC>Здравствуйте, DarkGray
AC>Могу привести в качестве примера современную электронику, где решение проблемы, в большинстве случаев, сводится к выбору нужных "кубиков".
Это потому что в электронике зачастую решаются типовые задачи. Как только появляются нестандартные задачи, в дело идут микроконтроллеры а, в тяжелых случаях — ПЛИСы и DSP, а это уже набивание текста и программизм в полный рост.
Здравствуйте, Real 3L0, Вы писали:
0>>Потому, что эти "кубики" не устраняли главной сложности в программировании, они решали не ту проблему. R3>А какую проблему они решали?
Главная проблема программирования это большое количество сущностей. Но об этом мало кто задумывается, ломая копья по поводу синтаксиса. Хотя замена синтаксиса на другой это обычно "те же яйца — вид сбоку" вместо упрощения.
