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

V>Вообще-то, бизнес-аналитик для того и нужен, чтобы формализовать задачу.

Это разные степени формализации.

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

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

V>>Вообще-то, бизнес-аналитик для того и нужен, чтобы формализовать задачу.

AVK>Это разные степени формализации.


Я имею ввиду, когда бизнес-аналитики занимаются формализацией бизнес-процессов. Дак вот, с точки зрения бизнес-домена, степень формализации максимальная: с блок-схемами и четким описанием всех возможных случаев. Собственно, для этого DSL и нужен, чтобы покрыть бизнес-домен и отгородиться от технической части и чтобы аналитики формализовали процессы сразу на DSL.

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

V>Я имею ввиду, когда бизнес-аналитики занимаются формализацией бизнес-процессов.

Я тебя понял. Ответ тот же.

V> Дак вот, с точки зрения бизнес-домена, степень формализации максимальная

Ни в коем случае. Аналитик описывает грубую структуру предметной области и крупномасштабный алгоритм. Формализация абстрактной структуры и алгоритмов до конкретики используемой платформы не является его задачей.

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

AVK>Ни в коем случае. Аналитик описывает грубую структуру предметной области и крупномасштабный алгоритм. Формализация абстрактной структуры и алгоритмов до конкретики используемой платформы не является его задачей.

Еще раз, я про других бизнес аналитиков, которым не надо структуру предметной области описывать — она уже описана. Я про тех, которые решают, заказ сразу пойдет на производство, или сначала его должен заапрувить Иван Иваныч. Или если сумма заказа меньше 100 рублей, то сразу в производство, иначе Иван Иванычу. Сегодня 100 рублей, через неделю уже 150. Еще через неделю определенные заказы должны пойти Семен Семенычу вместо Иван Иванычу.

Короче говоря, есть проект для одной очень большой компании, которая хочет, чтобы её бизнес-аналитики получили инструмент, с помощью которого они сами задавали бизнес-процессы без обращения в IT. Там должен быть особый бизнес-процесс создания нового бизнес-процесса, и т.д. Вобщем, эту задачу я не из пальца высосал

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

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

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

V> Я про тех, которые решают, заказ сразу пойдет на производство, или сначала его должен заапрувить Иван Иваныч.

Какая то у тебя каша с понятиями. Решения о порядке разработки и набора реализуемых требований принимают вообще не технические специалисты, а менеджеры — ПМ и т.п.

V>Короче говоря, есть проект для одной очень большой компании, которая хочет, чтобы её бизнес-аналитики получили инструмент, с помощью которого они сами задавали бизнес-процессы без обращения в IT. Там должен быть особый бизнес-процесс создания нового бизнес-процесса, и т.д. Вобщем, эту задачу я не из пальца высосал

Испугал. Я и постраннее задачи видел.

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

AVK>Если бизнес-аналитик описывает задачу в терминал целевой платформы на основании уже готового абстрактного описания модели, то это уже никакой не бизнес-аналитик, а самый настоящий программист.
Все верно, только термины целевой платформы совпадают с терминами бизнес-домена, и эти "программисты" не знают ни сишарп, ни тем более немерле.

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

V>Все верно, только термины целевой платформы совпадают с терминами бизнес-домена

Только частично. Полного совпадения в прироже не бывает.

V>, и эти "программисты" не знают ни сишарп, ни тем более немерле.

Ну и что? Программисты на 1С тоже ничего этого не знают, вот только результатом снижение гибкости, производительности, качества.

Здравствуйте, Чистяков Влад (VladD2), Вы писали:

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

Что касательно языков программирования и технологий, Майкрософт опирается на понятие Learning Curve.
http://en.wikipedia.org/wiki/Learning_curve
За этим стоит простая посылка — технологии должны развиваться эволюционно, чтобы быть легко принятыми широкой общественностью. Их можно понять — Майкрософту надо зарабатывать деньги "здесь и сейчас", C# — не продукт динамичного "стартапа", он изначально позиционировался как мэйнстримовый продукт.

Примеры революционных технологий, таких как UNIX и C — проходит довольно продолжительный период времени для их адаптации. Сначала они получили популярность в университетах, и только потом — стали входить в общую практику, вместе с выпускниками этих университетов. Более свежий пример — Java. Сколько лет прошло с момента ее появления, прежде чем Java заняла свое прочное место на корпоративных серверах и мобильных устройствах?

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

И третье условие, которое может погубить "первый заход" новой технологии — она должна появиться вовремя. Не раньше и не позже, а ровно тогда, когда надо. "Когда надо" обуславливает изменением приоритетов потребностей потребителей во времени. С этим "когда надо" все постоянно ошибаются, поэтому далеко не обязательно первый, кто выходит на рынок, получает этот рынок. Пример. AMD в начале 2000-х разработала революционное семейство систем на кристалле Alchemy, обладающее очень низким энергопотреблением. Однако, они вышли с таким продуктом на рынок слишком рано, настоящий спрос на такие решения появился только в последние годы, а ждать несколько лет — это экономически накладно, это равносильно коммерческому провалу проекта. Поэтому, AMD продала всю эту линейку продуктов с потрохами по демпинговой цене другой компании несколько лет назад, мелкой какой-то компании, забыл как называется.

Одним из признаков, который позволяет определять правильные точки входа, пусть во многом и пост-фактум, является измерение "хайпа", шума вокруг технологий. А именно — Гартнеровский Hype Cycle.
http://www.gartner.com/pages/story.php.id.8795.s.8.jsp

What is a Hype Cycle?

A Hype Cycle is a graphic representation of the maturity, adoption and business application of specific technologies.

Since 1995, Gartner has used Hype Cycles to characterize the over-enthusiasm or "hype" and subsequent disappointment that typically happens with the introduction of new technologies (see Understanding Gartner's Hype Cycles) for an introduction to the Hype Cycle concepts). Hype Cycles also show how and when technologies move beyond the hype, offer practical benefits and become widely accepted. Read More.

Гартнер выпускает собственные "карты технологий", где наносят положение существующих технологий на график хайп-цикла, и цветом точки обозначают период ее выхода на "плато продуктивности". Так вот, Майкрософт, основываясь на коротком learning curve, берет к адаптации технологии, близкие по времени к "плато продуктивности" (то есть, те, которые за время разработки окажутся в правильном месте — после первого пика, а не до). В этом и состоит причина, почему они тормозят. По сути своей, у Майкрософта плохо выходит рисковать, зато в рамках этой стратегии она вполне успешна. Критиковать за это Майкрософт не стоит — они поступают как крупная корпорация, а не маленький стартап. При этом, не забываем про Microsoft Research, который специально создан, чтобы исследовать перспективные технологии, которым далеко до плато продуктивности. Скажем, она финансирует работы связанные с Хаскелем, F#, и много еще чего.

Вот и все. Нарисуй Немерле на кривой Гартнеровского Хайп Цикла, и посмотри сам, где он находится. О метапрограммировании только-только начинают говорить, и мы даже не достигли первого пика.

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

G>О метапрограммировании только-только начинают говорить, и мы даже не достигли первого пика.

А чем же тогда был Lisp?

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

G>>О метапрограммировании только-только начинают говорить, и мы даже не достигли первого пика.

E>А чем же тогда был Lisp?

Lisp, насколько я помню, в свое время поднялся на хайпе исскуственного интеллекта, а не метапрограммирования, и вместе с ним упал.

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

M>>Именно платформа определяет — как будет реализован фреймворк/api.
M>>Будет в платформе паттерн-мэтчинг, будут замыкания — и фреймворк будет реализован совершенно иначе.

V>Не важно, как он реализован, важно, что торчит наружу.

M>>И эта иная реализация может кардинально улучшить использование фреймворка.

V>Приведи пример кардинального улучшения. Я вот кроме как стандартных дженерик-коллекций ничего не могу вспомнить. Зато я могу вспомнить, как язык неоднократно подгоняли в угоду фреймворку и средствам разработки.

Легко. Сравни STL со всеми предыдущими контейнерными библиотеками. А ведь STL задействует и полагается на всего лишь пару фич языка — шаблонные функции, и "функторы", которые позволяют выражать замыкания и функции высшего порядка. Применение последних _концепций_ и делает библиотеку настолько выразительной и простой.

Вы вооще не то немного обсуждаете оба. Не надо смешивать "синтаксический сахар" и концепции, заложенные в язык (чем одно время грешил Влад, с него видать это и пошло). Как только вы начнете эти вещи разделять, тогда все встанет на свои места. Когда вы применяете другие концепции, вы не просто можете отдельный "алгоритм" записать лучше. У вас вся система будет выстроена по другому принципу, потому что вы думаете в других терминах. От этого эффект и есть, и это отлично демонстрирует STL, а также билиотеки Хаскеля и Эрланга. Но начать думать в этих "других" концепциях — и наиболее тяжело. Вот они медленно и меняются.

Вспомните С++. Если относится к нему как к "С с классами" (а так и было по началу), то он мало чего дает. Однако, в сочетании с новыми стилями мышления для С-программиста, которые реализуемы в С++ — это уже совершенно другой язык.

Вот взять макросы. Сами по себе макросы — фигня, и язык без стоящей за ним парадигмы — будет не более чем "С с классами". Однако, есть концепция, которую на полную катушку раскрывают макросы — это Model-Driven Development, а это уже гораздо больше чем макросы.
http://en.wikipedia.org/wiki/Model_driven_development
Популярность этого подхода будет являться одним из двигателей макросредств.

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

G>Одним из признаков, который позволяет определять правильные точки входа, пусть во многом и пост-фактум, является измерение "хайпа", шума вокруг технологий. А именно — Гартнеровский Hype Cycle.
G>http://www.gartner.com/pages/story.php.id.8795.s.8.jsp

Смешной мужик.
По сути — что он исследует? Он рисует результаты социодинамики вокруг цикла развития технологии. Небольшого куска полного цикла.
Мы все в школе физику учили. Там как нас учили вычислять положение тела — текущая позиция + скорость движения * время.
Так же и в технологии — текущий уровень + тенденции * время.
Простая интерполяция, работающая на небольшом отрезке времени. Если надо получить позицию через более длительный промежуток
времени — надо учитывать силы действующие на тело, они вызывают ускорение, изменение скорости.
Для технологий аналог силы — это причины. Причины вызывают изменение тенденций.
О чём рассказывает Гартнер? Он даже не о тенденциях говорит, он говорит о социодинамике вокруг тенденций.
О наблюдаемом непосредственно.
Это как в астрономии описывать движения планет непосредственно — у них и скорость меняется, и иногда они даже
начинают двигаться в обратную строну, и всё это тщательно промеряно и на основе предыдущих промеров вычисляются
положения планет в будущем. А если описывать через причины, через законы гравитации — то получается очень простая
картина, планеты движутся по элипсу вокруг солнца. Если ты знаешь силы действующие на планеты — то
задача тривиальна. Если не знаешь — то задолбаешься понимать.

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

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

G>>Одним из признаков, который позволяет определять правильные точки входа, пусть во многом и пост-фактум, является измерение "хайпа", шума вокруг технологий. А именно — Гартнеровский Hype Cycle.
G>>http://www.gartner.com/pages/story.php.id.8795.s.8.jsp

M>Смешной мужик.
M>По сути — что он исследует?

LOL Ы-ы-ы...

Gartner, Inc. (NYSE: IT) is the world’s leading information technology research and advisory company. We deliver the technology-related insight necessary for our clients to make the right decisions, every day. From CIOs and senior IT leaders in corporations and government agencies, to business leaders in high-tech and telecom enterprises and professional services firms, to technology investors, we are the indispensable partner to 60,000 clients in 10,000 distinct organizations. Through the resources of Gartner Research, Gartner Executive Programs, Gartner Consulting and Gartner Events, we work with every client to research, analyze and interpret the business of IT within the context of their individual role. Founded in 1979, Gartner is headquartered in Stamford, Connecticut, U.S.A., and has 4,000 associates, including 1,200 research analysts and consultants in 80 countries.

While we are the largest company of our kind, we remain highly accessible to our clients. Gartner was founded in 1979 by technology thinkers who saw the growing need for well-researched, independent advice. Our culture is still based on the diligent work of exceptional thinkers acting together to apply the very latest knowledge rapidly and effectively.

Ты что, правда не знаешь, что это "за мужик", и "что он по сути исследует"? Вот уж воистину смешной мужик. Ты новости вообще читаешь? Никогда фразу "по данным Gartner" не встречал?

Смотри — это самое лучшее аналитическое агество в мире в области хайтека.
http://gartner.com/
А вот это — второе, не менее авторитетное аналитическое агество в мире в области хайтека:
http://idc.com/

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

M>задача тривиальна. Если не знаешь — то задолбаешься понимать.

И не говори!

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

G>Ты что, правда не знаешь, что это "за мужик", и "что он по сути исследует"? Вот уж воистину смешной мужик. Ты новости вообще читаешь? Никогда фразу "по данным Gartner" не встречал?

G>Смотри — это самое лучшее аналитическое агество в мире в области хайтека.


Смешно разговаривать с людьми, которые вместо аргументов приносят справку о крутости авторитета , которого они цитируют.
Никто не оспаривает крутости Аристотеля, но как по мне, то лучше пользоваться моделью движения планет от Коперника.

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

M>Смешно разговаривать с людьми, которые вместо аргументов приносят справку о крутости авторитета , которого они цитируют.
M>Никто не оспаривает крутости Аристотеля, но как по мне, то лучше пользоваться моделью движения планет от Коперника.

А от чего ж Коперника? Или в верности его теории вы убедились непосредственно?

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

C>а ты считаете Фишера идейным, ИМНО он просто религиозный фанатик (вспомнить хотя бы его отказы играть по субботам).
C>Некоторые великие шахматисты закончили свой жизненный путь в психиатрических клиниках...

Это рассказ не про Фишера, а про свободу слова (мысли, дела, ...) в США.

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

E>Поскольку бизнес -- это постоянно противостояние конкрурентов со своей "гонкой вооружений", то нет ничего удивительного, что монстры бизнеса придерживаются тех же приемов, что и военные.

Теория правдоподобная...

E>Только вот я не увидел в статье Влада желания узнать, почему же существует последовательность "отрицание, замалчивание, пиар, реализация, популяризация"

Меня удивляет две вещи.
1. Зачем так громко отрицать нужность того, что потом все же оказывается очевидным и нужным?
2. Почему люди не упорно сопротивляются использованию продвинутых технологий (в данном случае упрощающих добавление и апробацию новых фич в ЯП) затягивая тем самым процесс разработки новых фич на долгие годы?

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

M>MS и так уже упёрлась в предел сложности программного обеспечения, они не могут себе позволить совать в .NET всё подряд — иначе
M>следующая версия не через 3 года выйдет, а через 30.

Ты сам себе противоречишь. Если кто-то упирается в предел сложности, то чтобы его преодолеть в первую очередь начинают использовать более продвинутые инструменты и технологии.
Просто глупо пытаться создать супер-современный процессор с помощью технологий 19-го века. И уж просто маразматично делать это каменным молотком. Но почему-то тоже самое в разработке ПО удивления почти ни у кого не вызывает. И даже наоборот, многие начинают защищать "умельцев каменного топора".

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

V>>Дело не в мусоре. К мусору привыкаешь и перестаешь замечать,
WH>Именно в мусоре.
WH>Ибо из тонны мусора приходится выкапывать полезные данные.

Дело не только в мусоре.
Дело еще и в голове. Блаб не понимающий что написано в коде оценит самый выразительный и лаконичный код как совершенно запутанный и непонятный.

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

VD>>Это взгяд того самого блаба. Ты попросту не видишь других решений. Меж тем они есть. Скажем твою задачу можно описать куда проще чем ты можешь это сделать сегодня (известными тебе средствами).

V>Меня не интересует техническая реализация решения — запрограммировать не проблема, это дело техники, прошу прощения за тафталогию. Сложность не в этом.

Если бы запрограммировать небыло бы проблемой, то твой труд был бы никому не нужен, так как пара индусов давно написала бы весь код (или это сделали бы сами пользователи).

VD>>Простой пример. Ты знаком с XSLT?

V>Ага.

А пользовался им?
Если ответ — да, то еще один вопрос. А пробовал ли ты преобразовывать XML без XSLT (или аналогичного инструмента)? Ну, скажем через DOM?
Любой кто это делал знает, что использовать XSLT на порядок продуктивнее.
Точно так же на порядок продуктивнее использовать и другие инструменты. Вот для развития того же компилятора продуктивнее использовать квази-цитирование и подсистему вроде макросов. Но в МС это пока что просто не понимают. И это не смотря на то, что у них есть F# в котором квази-цитирование присутствует.

Точно так же возможность создания встроенных (в основной универсальный язык) микро-DSL-ей способно поднять производительность прикладника. Ведь код будет получаться более высокоуровневый. В нем можно допускать меньше ошибок. Ведь отладка ДСЛ-я намного проще чем отладка гор кода написанного без его использования.

VD>>Вот в этом и проблема. И пока ты не сделаешь шаг в эту сторону мы друг друга никогда не поймем. Но тебе проще себя успокоить, чем делать какие-то шаги. Ведь с точки зрения тебя с твоими теперешними знаниями, ты решаешь задачи оптимальным образом. И ты прав. Но эта правода определяется твоими теперешними знаниями и опытом. Как только твои знания и опыт расширятся, то нам с тобой и спорить будет не о чем. Вот такой вот парадокс.

V>Я не только решаю сам, но и наблюдаю за решениями других. Сравниваю, и делаю выводы.

Что ты решаешь? Ты точно верно прочел мои слова?

VD>>ОК. А как тебе идея создания некого инструмента реально упрощающего создание фрэмвороков и даже позволяющего встроить этот фрэймворк в твою повседневную рабочую среду.

V>Замечательно, но только при условии, что программы, написанные на разных языках, не будут смешиваться друг с другом. "Котлеты отдельно, мухи отдельно".

Ага. И по этому ты ни разу так и не создал ни одного инструмента который бы тебе помог. Вместо этого ты долбишь землю каменной мотыгой и споришь с теми кто тебе предлагает использовать трактор и плуг.