Re[20]: Паттерны проектирования - копипаста!
От: WolfHound  
Дата: 31.08.12 13:42
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Linq используется куда большче, чем в 5 случаях и тем не менее остаётся конкретным случаем, а не всемогутором.

Ты вообще прочитал написанное? Тут написано, что Linq не адекватен для многих случаев. Это факты. И никакой демагогией ты тут не отвертишься.
И из этих фактов следует что его проще переизобрести для разных случаев чем каждый страдать от того что есть лишние и не хватает нужных ключевых слов.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Паттерны проектирования - копипаста!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 31.08.12 13:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Эту модель придумал не микрософт. Я например эту аббревиатуру видел в книгах и либах еще до того, как на винду перешел.

WH>А гугл про нее не знает. Значит аббревиатура, мягко говоря, редкая.

Гугл про неё знает, только совпадающие аббревиатуры к программухе не относятся и на порядки более популярны чем любой запрос по программухе.

I>>Ничем не отличается от примера в конце сообщения.

WH>Правда? Тот код строго последовательный. А пользователь тыкает, куда попало в произвольном порядке... Это тебя не смущает?

Правда. Нисколько.

I>>Как это упрощает жизнь в эрланде и аксуме понятно ?

WH>Как это поможет при создании ГУИ не понятно.

ГУИ они разные. Там где контента много, а получить уведомления об изменении модели сложно, ViewModel не годится. Он годится для случаев, когда контента мало и изменения хорошо локализованы и легкодоступны.

I>>Axum например сдох не родившись. Эрланг есть только в узкой нише. Нужен точно такой же механизм но в самом массовом ЯП безо всяких эмуляций.

WH>Не правильно. Нужен механизм расширения языков.
WH>Тогда мы сможем сделать всё, что нам нужно.
WH>В том числе и данную функциональность. Без всяких эмуляций.
WH>Посмотри, что народ с немерлом делает.
WH>http://user1663.netfx45lab.discountasp.net/
WH>Сколько ты будешь ждать пока микрософт изволит повторить?

Извини, я в вебе мало чего понимаю.

I>>Поздравляю, ты открыл америку.

I>>Цитирую себя: "нужно изыскивать решения для приведения энергичного кода в ленивый. Если такой инструмент появится"
I>>Тебе все здесь понятно ?
WH>Да.
WH>Ты понимаешь, что натягивание фичей на язык, в котором этих фич нет плохо.

OMG !!! Сравни "Если такой инструмент появится" c "такой инструмент появился и это yield return в C#"

WH>Но почему-то споришь с необходимостью расширяемых языков в которые можно добавить любую фичу без компромиссов.


Пока нет вакансий по Nemerle им смело можно пренебречь. Я не люблю экспериментировать на себе.

WH>И к чему этот говнокодище?

WH>Асинхронное программирование получается ужасным. Проще чем пилить всё на калбеках, но всё равно ужасно.

Разумеется, потому что нет поддержки в языке.
Нужна возможность описать конкретный воркфлоу в одной единсвенной функции, даже если кнопочки ты нажимаешь где попало. Как это будет выполняться, синхронно, асинхронно — дело десятое. Главное что энергичный код будет сделан ленивым.

WH>Реактивное вообще не получается.


Ты похоже вообще не читаешь.
Re[21]: Паттерны проектирования - копипаста!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 31.08.12 13:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Ikemefula, Вы писали:


I>>Linq используется куда большче, чем в 5 случаях и тем не менее остаётся конкретным случаем, а не всемогутором.

WH>Ты вообще прочитал написанное? Тут написано, что Linq не адекватен для многих случаев. Это факты.

Правильно. Но он не писался в духе "для 5 случаев".

WH>И из этих фактов следует что его проще переизобрести для разных случаев чем каждый страдать от того что есть лишние и не хватает нужных ключевых слов.


Разумеется, а еще проще изобретать его для каждого случая — бери да копипасти.
Re[21]: Паттерны проектирования - копипаста!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 31.08.12 13:54
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Все его посты состояли из фразы "это не важно" чуть менее чем полностью.

I>>Это мягко говоря враньё.
WH>Открой ветку да посмотри. Ничего по существу задачи он не сказал.

Но ты вещаешь как будто у него и работаешь

I>>Разумеется под оба. И это не значит, что получится всемогутор.

WH>Ты говоришь именно про всемогутер. Ибо разные 5 случаев могут только казаться похожими.

Нет, по моему "очень похожи" и "только кажутся похожими" это разные вещи и про это в том сообщении ничего нет.
ты не у hi_octane работаешь ?

I>>Что получается в проекте, если пилить под каждые 5 случаев использования я уже описывал — хаос.

WH> Ничего ты не описывал. И описывать не мог. Максимум фантазировать. Ибо опыта в данном вопросе у тебя нет.

Очередное враньё в твоем исполнении
http://rsdn.ru/forum/philosophy/4718846.1.aspx
Автор: Ikemefula
Дата: 27.04.12


Re[13]: Паттерны проектирования - копипаста!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 31.08.12 14:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Теперь взгляни на себя со стороны — ты предлагаешь для проектов, где техническая сложность нулевая, набрать суровых архитектором с десятками лет опыта

WH>Если этим архитекторам дать ДСЛ. А для данных типовых проектов легко делается типовой ДСЛ. То они будут делать эти проекты настолько быстрее, дешевле и качественней студентов, что даже не смешно.

Они вообще это не будут делать, им это скучно.

WH>Делать проекты тупыми инструментами и тупыми исполнителями это очень дорого и рискованно.


Девелоперу высокого класса нужны высококлассные задачи иначе ему будет скучно и он завалит проект именно по этой причине.

WH>>>Я смогу понять это через пару недель после начала работы глядя на код. Что может не программист на данном этапе? А ничего он не сможет. Он просто не поймет все эти закорючки.

I>>См. выше.
WH>Не виляй.
WH>Как не программист сможет понять, что проект идет в говно?
WH>Ответ на этот простой вопрос будет?

Определись для себя, как говнокод влияет на результат и в чем это может проявляться.

Если не влияет, вопрос закрыт. Если влияет, то как именно.
Динамика багов отражает проблемы в проекте, это что, новость ? Прогонять сценарии пользоваля это новость ? Контрибутить баги это новость ? Отслеживать расход времени на разработку это тоже по твоему новость ?
С такими вопросами ты, походу, кроме как в одиночку то и не работал нигде. Соболезную.

I>>на проект нужно набирать людей в соответсвтии с 1 технической сложностью проекта 2 состоянием рынка труда.

I>>Про техническую сложность см выше.
WH>Это не важно. Неучи всё равно не справятся.

Неучи конечно не справятся, а для 80-90% задач за глаза хватает людей от студента 4го курса до молодого специалиста с опытом 5 лет.

I>>Доволен результатом значит заказчик достиг с помощью софта свои цели, в контексте бизнеса конечно. НАпример заказчику нужна была автоматизация некоторых рабочих мест. Пошел профит == заказчик доволен.

WH>Только заказчик не знает, что профит мог бы быть намного больше.

Возможный профит оценивается заранее и заказчик или соглашается на него или не соглашается. Например — хочу серверный софт под 1000 юзеров. Ему говорят — можем 100 за 9 млн $, он говорит — хорошо. Или так — пошли нахрен. Или так — может 1000 за 20 млн $, тут тоже варианты, от "хорошо" до "пошли нахрен"

WH>А если бы он знал что вместо его мотыги ему дали лошадь с плугом (относительно мотыги пошёл профит), а могли бы дать трактор, причем в несколько раз дешевле, чем он заплатил за клячу и на год раньше...


И где ты таких тупых заказчиков берешь ?

WH>Короче к прокурору.


Может чтото не так, если у тебя такие заказчики тупые ?

I>>Если заказчику насрать, что на его стороне плак и ной, то странно ожидать толковых требований. А если не насрать, то неясно, к чему твой пример.

WH>К тому что "успех" проекта, который сделали неучи, может быть лишь видимостью обусловленный массой факторов, которые не связаны с самим проектом.

Эта "видимость" почему то воспроизводится слишком регулярно.
Re[18]: Паттерны проектирования - копипаста!
От: WolfHound  
Дата: 31.08.12 14:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Гугл про неё знает, только совпадающие аббревиатуры к программухе не относятся и на порядки более популярны чем любой запрос по программухе.

Её даже в википедии нет. Короче неуловимый Джо как он есть.

WH>>Правда? Тот код строго последовательный. А пользователь тыкает, куда попало в произвольном порядке... Это тебя не смущает?

I>Правда. Нисколько.
Мда.

I>ГУИ они разные. Там где контента много, а получить уведомления об изменении модели сложно, ViewModel не годится. Он годится для случаев, когда контента мало и изменения хорошо локализованы и легкодоступны.

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

WH>>http://user1663.netfx45lab.discountasp.net/

WH>>Сколько ты будешь ждать пока микрософт изволит повторить?
I>Извини, я в вебе мало чего понимаю.
Не виляй. Это чистый MVVM.
Из ВЕБ там только примитивный HTML который не знать невозможно.

I>OMG !!! Сравни "Если такой инструмент появится" c "такой инструмент появился и это yield return в C#"

Он не появился. yield return данную задачу не решает.

I>Пока нет вакансий по Nemerle им смело можно пренебречь. Я не люблю экспериментировать на себе.

Есть. Я сейчас пишу на немерле за зарплату выше рынка.

I>Разумеется, потому что нет поддержки в языке.

А несколькими строчками ты утверждал, что это yield return.

I>Нужна возможность описать конкретный воркфлоу в одной единсвенной функции, даже если кнопочки ты нажимаешь где попало. Как это будет выполняться, синхронно, асинхронно — дело десятое. Главное что энергичный код будет сделан ленивым.

Зачем в ГУИ "воркфлоу"?
Короче повтори на этом своем "воркфлоу" в том синтаксисе, который тебе нравится любую из демок http://user1663.netfx45lab.discountasp.net/

WH>>Реактивное вообще не получается.

I>Ты похоже вообще не читаешь.
Я тебе показал, что такое реактивное программирование.
То, что ты показываешь, к нему не относится.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Паттерны проектирования - копипаста!
От: WolfHound  
Дата: 31.08.12 14:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Правильно. Но он не писался в духе "для 5 случаев".

И поэтому он не подходит ни для одного.

I>Разумеется, а еще проще изобретать его для каждого случая — бери да копипасти.

Так что ты будешь делать с лишними словами? И что более важно с теми, которых не хватает?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Паттерны проектирования - копипаста!
От: WolfHound  
Дата: 31.08.12 15:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

WH>>Если этим архитекторам дать ДСЛ. А для данных типовых проектов легко делается типовой ДСЛ. То они будут делать эти проекты настолько быстрее, дешевле и качественней студентов, что даже не смешно.

I>Они вообще это не будут делать, им это скучно.
На C# скучно. Но когда у тебя ДСЛ то нет.
Ибо 99% процентов времени он будет тратить на анализ задачи.
А её запись на ДСЛ будет короче, чем на русском.

I>Определись для себя, как говнокод влияет на результат и в чем это может проявляться.

Мда. Говнокод заваливает проекты. Причем если первую итерацию еще иногда удаётся сдать, то поддержка будет адом.

I>Если не влияет, вопрос закрыт. Если влияет, то как именно.

I>Динамика багов отражает проблемы в проекте, это что, новость ? Прогонять сценарии пользоваля это новость ? Контрибутить баги это новость ? Отслеживать расход времени на разработку это тоже по твоему новость ?
1)Что из этого знает человек, который в разработке программ ничего не понимает.
2)Если он видит что багов много что дальше? Он не знает причину. И исполнители будут вещать, что это всё нормально. Так у всех и всегда. И скоро они всё исправят. Не забывай, по твоей версии заказчик в программировании ничего не понимает.

I>Неучи конечно не справятся, а для 80-90% задач за глаза хватает людей от студента 4го курса до молодого специалиста с опытом 5 лет.

Без опытного надсмотрщика они завалят проект с вероятность 99%.
А с опытным надсмотрщиком им на порядок эффективнее дать ДСЛ.

WH>>Только заказчик не знает, что профит мог бы быть намного больше.

I>Возможный профит оценивается заранее и заказчик или соглашается на него или не соглашается. Например — хочу серверный софт под 1000 юзеров. Ему говорят — можем 100 за 9 млн $, он говорит — хорошо. Или так — пошли нахрен. Или так — может 1000 за 20 млн $, тут тоже варианты, от "хорошо" до "пошли нахрен"
И как он узнает что:
Исполнитель может это сделать?
И главное что сервер под 100К пользователей на самом деле стоит 100К$?

Он же в программировании ничего не понимает.

WH>>А если бы он знал что вместо его мотыги ему дали лошадь с плугом (относительно мотыги пошёл профит), а могли бы дать трактор, причем в несколько раз дешевле, чем он заплатил за клячу и на год раньше...

I>И где ты таких тупых заказчиков берешь ?
Я? Это ты их берешь.
Ибо те, кто доволен деятельностью студентов, попадают именно в эту категорию.

I>Эта "видимость" почему то воспроизводится слишком регулярно.

1)Заказчик не знает, что его кинули.
2)Конкретным людям со стороны заказчика не выгодно поднимать шум.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Паттерны проектирования - копипаста!
От: WolfHound  
Дата: 31.08.12 15:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

WH>>>>Все его посты состояли из фразы "это не важно" чуть менее чем полностью.

I>>>Это мягко говоря враньё.
WH>>Открой ветку да посмотри. Ничего по существу задачи он не сказал.
I>Но ты вещаешь как будто у него и работаешь
Не улавливаю логику. Из чего получается, что я работаю у AVK? Если бы я у него работал, я бы понимал его пример.

I>Нет, по моему "очень похожи" и "только кажутся похожими" это разные вещи и про это в том сообщении ничего нет.

Но ты строишь далеко идущие выводы, по которым получается что hi_octane делает лишнюю работу.

WH>> Ничего ты не описывал. И описывать не мог. Максимум фантазировать. Ибо опыта в данном вопросе у тебя нет.

I>Очередное враньё в твоем исполнении
I>http://rsdn.ru/forum/philosophy/4718846.1.aspx
Автор: Ikemefula
Дата: 27.04.12

Ты там так и не рассказал, что там происходит. Да и не ты это делал.
Всё что ты продемонстрировал это полную неспособность сформулировать задачу.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Паттерны проектирования - копипаста!
От: Abyx Россия  
Дата: 31.08.12 15:28
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Пока нет вакансий по Nemerle им смело можно пренебречь. Я не люблю экспериментировать на себе.

WH>Есть. Я сейчас пишу на немерле за зарплату выше рынка.

тогда тебе надо уволиться.
создай вакансию — поддержи немерле!
In Zen We Trust
Re[20]: Паттерны проектирования - копипаста!
От: WolfHound  
Дата: 31.08.12 15:58
Оценка: +1
Здравствуйте, Abyx, Вы писали:

A>тогда тебе надо уволиться.

A>создай вакансию — поддержи немерле!
Напротив. Если останусь, вакансий будет намного больше.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Паттерны проектирования - копипаста!
От: koodeer  
Дата: 31.08.12 16:57
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Архитектур насоздавали тонны, а язык родили всего один.


Потому что нет удобных средств создания языков! Немерлисты постоянно талдычат об этом. Были бы такие средства — новые языки пеклись бы как пирожки.

Между тем, одним из таких средств является xml. Чтобы создать новый язык на базе xml достаточно определить схему. Определяем схему — получаем язык разметки, или даже язык программирования — XSLT. И такие языки клепаются десятками! Возьмём XAML — это новый язык. Причём внутри него реализован ещё один DSL — язык привязки данных.

Причём, задав схему, мы автоматически получаем автокомплит и подсветку в любом продвинутом xml-редакторе. Конечно, язык на базе xml, какую схему не определяй, синтаксически останется похож на xml, никуда от этого не деться. Большой недостаток — многословность xml, это мало кому нравится, поэтому такой способ DSL-строения не шибко популярен.
Re[9]: Паттерны проектирования - копипаста!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.09.12 20:39
Оценка:
Здравствуйте, koodeer, Вы писали:

I>>Архитектур насоздавали тонны, а язык родили всего один.


K>Потому что нет удобных средств создания языков! Немерлисты постоянно талдычат об этом. Были бы такие средства — новые языки пеклись бы как пирожки.


И какой инструмент поможет тебе изобрести абстракции за 1 год а не за 15 лет, как это было в обсуждаемом случае ?

Пойми простую вещи, родить первые попавшиеся абстракции в виде языка очень легко и код, как говорит WH, будет скатываться в говно.
Очень трудно предложить качественные абстракции, на такое способно очень малое количество людей, много меньшее чем количество хороших архитекторов
Re[23]: Паттерны проектирования - копипаста!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.09.12 20:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Но ты вещаешь как будто у него и работаешь

WH>Не улавливаю логику. Из чего получается, что я работаю у AVK? Если бы я у него работал, я бы понимал его пример.

Перепутать авк и хайоктан — доказательство что ты вообще не помнишь контекст

I>>Нет, по моему "очень похожи" и "только кажутся похожими" это разные вещи и про это в том сообщении ничего нет.

WH>Но ты строишь далеко идущие выводы, по которым получается что hi_octane делает лишнюю работу.

Симптомы которые он перечисляет мне очень хорошо знакомы. Полной картины пока нет, но оснований для сомнений вполне достаточно.

WH>Ты там так и не рассказал, что там происходит. Да и не ты это делал.

WH>Всё что ты продемонстрировал это полную неспособность сформулировать задачу.

Вроде как в прошлый раз ты задачу правильно понял при чем предложил именно то решение от котог мы отказались. Не боись — я майнтейнил этот код достаточно долго что бы разобраться что к чему и какие проблемы дает тот подход который ты предлагаешь.
Re[23]: Паттерны проектирования - копипаста!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.09.12 20:50
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

I>>Правильно. Но он не писался в духе "для 5 случаев".

WH>И поэтому он не подходит ни для одного.

Вообще говоря линк подходит много где и всемогутором не является — ни разу.

I>>Разумеется, а еще проще изобретать его для каждого случая — бери да копипасти.

WH>Так что ты будешь делать с лишними словами? И что более важно с теми, которых не хватает?

Этот вопрос я задавал тебе раз 5 или 6. Если у тебя нет качественных абстракций, все твои языки будут мусором и тебе придется нанять человека вроде Эрика Мейера.
Re[15]: Паттерны проектирования - копипаста!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.09.12 21:16
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>>>Если этим архитекторам дать ДСЛ. А для данных типовых проектов легко делается типовой ДСЛ. То они будут делать эти проекты настолько быстрее, дешевле и качественней студентов, что даже не смешно.

I>>Они вообще это не будут делать, им это скучно.
WH>На C# скучно. Но когда у тебя ДСЛ то нет.
WH>Ибо 99% процентов времени он будет тратить на анализ задачи.
WH>А её запись на ДСЛ будет короче, чем на русском.

Да без разницы, на чём. Для 80-90% проектов техническая сложность около нуля. Высококлассных специалистом можно заинтересовать только этой самой технической сложностью.
Или ты и предлагаешь решить этот вопрос с помощью ДСЛ ?

I>>Определись для себя, как говнокод влияет на результат и в чем это может проявляться.

WH>Мда. Говнокод заваливает проекты. Причем если первую итерацию еще иногда удаётся сдать, то поддержка будет адом.

Это общие слова. Говнокод дает целый ряд наблюдаемых и проверяемых эффектов. Вопрос — тебе они известны ?

I>>Если не влияет, вопрос закрыт. Если влияет, то как именно.

I>>Динамика багов отражает проблемы в проекте, это что, новость ? Прогонять сценарии пользоваля это новость ? Контрибутить баги это новость ? Отслеживать расход времени на разработку это тоже по твоему новость ?
WH>1)Что из этого знает человек, который в разработке программ ничего не понимает.

Всё. И это не разработка, а управление. Например, тоже самое придется почти в любой другой области делать.

WH>2)Если он видит что багов много что дальше? Он не знает причину.


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

>И исполнители будут вещать, что это всё нормально. Так у всех и всегда.


Твой опыт/кругозор обсуждать не будем, идёт ?

>И скоро они всё исправят. Не забывай, по твоей версии заказчик в программировании ничего не понимает.


Правильно. Только пофиксить не получится и это вылезет в виде реопенов, новых багов, ошибок в эстимейтах и тд и тд.

I>>Неучи конечно не справятся, а для 80-90% задач за глаза хватает людей от студента 4го курса до молодого специалиста с опытом 5 лет.

WH>Без опытного надсмотрщика они завалят проект с вероятность 99%.

Зеваю — у меня в получае ходьбы есть около 5 крупных контор, у которых контингент это люди от студентов до 5 лет опыта и представь, не только сущетсвуют, но еще и расширяются.

WH>А с опытным надсмотрщиком им на порядок эффективнее дать ДСЛ.


Опытному разрабу будет скучно, ему нужна техническая сложность.

WH>И как он узнает что:

WH>Исполнитель может это сделать?
WH>И главное что сервер под 100К пользователей на самом деле стоит 100К$?

Тендер. Отзывы. Похожие проекты. Консультации специальных контор. Я могу рассказать много вариантов как это делается.

WH>Он же в программировании ничего не понимает.


Эта проблема вообще в сфере услуг, а не только в программировании. И для неё есть решения.
Что самое интересное — ДСЛ здесь ничего не меняет. Студент научится лепить ДСЛ, впишет себе этот баззворд в резюме и его будут продавать заказчикам.

WH>>>А если бы он знал что вместо его мотыги ему дали лошадь с плугом (относительно мотыги пошёл профит), а могли бы дать трактор, причем в несколько раз дешевле, чем он заплатил за клячу и на год раньше...

I>>И где ты таких тупых заказчиков берешь ?
WH>Я? Это ты их берешь.

У меня к слову контора продуктовая, то есть продаём то что написали, чисто между прочим. Понятно, для тебя это ничего не меняет, потому что ты вообще не в курсе что это такое

WH>Ибо те, кто доволен деятельностью студентов, попадают именно в эту категорию.


Ты похоже так и не понял, что у каждого проекта есть определенная техническая сложность.

I>>Эта "видимость" почему то воспроизводится слишком регулярно.

WH>1)Заказчик не знает, что его кинули.

Заказчику нужен человек для выбора исполнителя, составления требований и для управления проектом. Если заказчик забивает на эти вещи, он сам себе злобный буратино. Как вариант — его проект уже изначально распильный.

WH>2)Конкретным людям со стороны заказчика не выгодно поднимать шум.


Заговор да по всему миру !!! Ты вообще в курсе, что студентов и молодых специалистов в раз больше чем опытных разрабов ?
Re[19]: Паттерны проектирования - копипаста!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.09.12 21:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Гугл про неё знает, только совпадающие аббревиатуры к программухе не относятся и на порядки более популярны чем любой запрос по программухе.

WH>Её даже в википедии нет. Короче неуловимый Джо как он есть.

Буду знать, какой источник является для тебя авторитетным

I>>ГУИ они разные. Там где контента много, а получить уведомления об изменении модели сложно, ViewModel не годится. Он годится для случаев, когда контента мало и изменения хорошо локализованы и легкодоступны.

WH>И в чем ты видишь проблемы?

Разумеется в сложности реализации взаимодействия.

WH>Или ты хочешь сказать, что виртуальные коллекции, которые физически загружают, только небольшое окно уже отменили?


Я хучу сказать, что вариантов UI намного больше чем "только небольшое окно"
Я тут скипнул чуток, нынче я в отпуске, случился перерыв между отдыхами

WH>>>http://user1663.netfx45lab.discountasp.net/

WH>>>Сколько ты будешь ждать пока микрософт изволит повторить?
I>>Извини, я в вебе мало чего понимаю.
WH>Не виляй. Это чистый MVVM.
WH>Из ВЕБ там только примитивный HTML который не знать невозможно.

Что мне должно быть понятно из примера для двух контролов ? Я не знаю сколько кода нужно другими инструментами.

I>>OMG !!! Сравни "Если такой инструмент появится" c "такой инструмент появился и это yield return в C#"

WH>Он не появился. yield return данную задачу не решает.

Правильно, не появился. Потому я и пишу "если ... появится" — это, на всякий, будущее время, а не прошедшее.

I>>Пока нет вакансий по Nemerle им смело можно пренебречь. Я не люблю экспериментировать на себе.

WH>Есть. Я сейчас пишу на немерле за зарплату выше рынка.

Три вакансии или сколько там, в джетбрейнс, не в счет. Эдак окажется что специалистов на нашем внутреннем дсл будет на порядок больше

I>>Разумеется, потому что нет поддержки в языке.

WH>А несколькими строчками ты утверждал, что это yield return.

"если ... появится" — это, как ты понимаешь, написано после того, как yield return уже появился. Подумай хорошо, чего ты хочешь сказать.

I>>Нужна возможность описать конкретный воркфлоу в одной единсвенной функции, даже если кнопочки ты нажимаешь где попало. Как это будет выполняться, синхронно, асинхронно — дело десятое. Главное что энергичный код будет сделан ленивым.

WH>Зачем в ГУИ "воркфлоу"?

Например для того, что бы качественно обрабатывать юзеринпут. Но вообще я не говорил что это нужно исключительно для ГУИ.

I>>Ты похоже вообще не читаешь.

WH>Я тебе показал, что такое реактивное программирование.
WH>То, что ты показываешь, к нему не относится.

Примеры для случае в два контрола меня не интересуют.
Re[24]: Паттерны проектирования - копипаста!
От: WolfHound  
Дата: 09.09.12 19:43
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Правильно. Но он не писался в духе "для 5 случаев".

WH>>И поэтому он не подходит ни для одного.
I>Вообще говоря линк подходит много где и всемогутором не является — ни разу.
Ага, конечно.
И по тому, что он так хорошо подходит народ пишет так
(from ...
select ...).Take(...)

Что же линк так сплоховал то?
Где слово take? А как насчет insert и delete? И главное где мой flatten?

WH>>Так что ты будешь делать с лишними словами? И что более важно с теми, которых не хватает?

I>Этот вопрос я задавал тебе раз 5 или 6.
Ты не мог задать этот вопрос. По тому, что ты даже не понимаешь где проблема.

I>Если у тебя нет качественных абстракций, все твои языки будут мусором и тебе придется нанять человека вроде Эрика Мейера.

Он сделал линк. Проблема линка в том, что идеологически там может быть весьма произвольный набор слов. Но реализация фиксирована.
И поэтому получается, что там либо есть лишние слов, либо не хватает слов и приходится лепить костыли типа того что выше. А обычно и то и другое.
Так что никто не может сделать фиксированный язык хорошо работающий всегда.
Следовательно, для любого фиксированного языка можно найти бесконечное множество задач, для которых он будет мусором.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Паттерны проектирования - копипаста!
От: WolfHound  
Дата: 09.09.12 19:43
Оценка:
Здравствуйте, Ikemefula, Вы писали:

WH>>>>>>>>Максимум, что было с вашей стороны, это AVK вывалил кусок кода, по которому ничего не ясно. На все вопросы были получены ответы из серии "это не важно".

I>>>>>>>АВК вдобавок объяснял десять или более постов.
WH>>>>>>Все его посты состояли из фразы "это не важно" чуть менее чем полностью.
I>>>>>Это мягко говоря враньё.
WH>>>>Открой ветку да посмотри. Ничего по существу задачи он не сказал.
I>>>>Но ты вещаешь как будто у него и работаешь
WH>>Не улавливаю логику. Из чего получается, что я работаю у AVK? Если бы я у него работал, я бы понимал его пример.
I>Перепутать авк и хайоктан — доказательство что ты вообще не помнишь контекст
Это кто тут контекст не помнит?

I>Симптомы которые он перечисляет мне очень хорошо знакомы. Полной картины пока нет, но оснований для сомнений вполне достаточно.

Они тебе не могут быть известны, поскольку ты не понимаешь предмет.

I>Вроде как в прошлый раз ты задачу правильно понял при чем предложил именно то решение от котог мы отказались. Не боись — я майнтейнил этот код достаточно долго что бы разобраться что к чему и какие проблемы дает тот подход который ты предлагаешь.

Но ты ничего не сказал. Всё что ты сказал сводится к реляционной алгебре.
И решается с пол пинка.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Паттерны проектирования - копипаста!
От: WolfHound  
Дата: 09.09.12 19:43
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Гугл про неё знает, только совпадающие аббревиатуры к программухе не относятся и на порядки более популярны чем любой запрос по программухе.

WH>>Её даже в википедии нет. Короче неуловимый Джо как он есть.
I>Буду знать, какой источник является для тебя авторитетным
Не является. Но если аббревиатура не попала даже туда, то значит, она волнует людей меньше чем немерле.

I>>>ГУИ они разные. Там где контента много, а получить уведомления об изменении модели сложно, ViewModel не годится. Он годится для случаев, когда контента мало и изменения хорошо локализованы и легкодоступны.

WH>>И в чем ты видишь проблемы?
I>Разумеется в сложности реализации взаимодействия.
Бла-бла-бла. Конкретики как обычно не будет?

WH>>Или ты хочешь сказать, что виртуальные коллекции, которые физически загружают, только небольшое окно уже отменили?

I>Я хучу сказать, что вариантов UI намного больше чем "только небольшое окно"
БРЕД! Просто по тому, что на экране может поместиться только очень не большое количество данных.

I>Что мне должно быть понятно из примера для двух контролов ? Я не знаю сколько кода нужно другими инструментами.

Ты тут вещаешь про UI а сам не знаешь как выглядит код для пары контролов на обычных технологиях?
Забавно.

I>"если ... появится" — это, как ты понимаешь, написано после того, как yield return уже появился. Подумай хорошо, чего ты хочешь сказать.

В очередной раз восстанавливаем контекст.

WH>>>>>И как это всё решает проблемы с асинхронным и реактивным программированием мне тоже совершенно не ясно.
I>>>>Я в курсе что тебе не ясно, не надо повторять.
WH>>>Ты делаешь заявления вселенского масштаба.
WH>>>Нужно выяснить, что за ними стоит.
WH>>>Выяснил. За ними стоит глупость такого же масштаба. Честно говоря, не удивлен.
I>>Думаю раз ты видишь эту глупость, то она на твоей стороне монитора, скорее всего в виде прослойки между креслом и монитором.
WH>Так ты код покажи. А то только болтаешь языком.
код по ссылке

.

Так зачем ты показал на yield return в качестве примера решения проблемы?

I>>>Нужна возможность описать конкретный воркфлоу в одной единсвенной функции, даже если кнопочки ты нажимаешь где попало. Как это будет выполняться, синхронно, асинхронно — дело десятое. Главное что энергичный код будет сделан ленивым.

WH>>Зачем в ГУИ "воркфлоу"?
I>Например для того, что бы качественно обрабатывать юзеринпут. Но вообще я не говорил что это нужно исключительно для ГУИ.
Опять бла-бла-бла.

WH>>Я тебе показал, что такое реактивное программирование.

WH>>То, что ты показываешь, к нему не относится.
I>Примеры для случае в два контрола меня не интересуют.
Ты не можешь показать всю круть своего подхода даже на двух контролах.

Перепиши пример Introduction из этой демки. http://user1663.netfx45lab.discountasp.net/
Посмотрим. Получится ли у тебя короче.
Можешь даже на воображаемом языке, в котором есть все нужные тебе плюшки писать.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.