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

S>Я имею примерно 20 лет опыта работы с СУБД; из них примерно 10 — с SQL.

Синклер, тебе ведь где-то 30 лет?! Ты что с СУБД с 10 лет работаешь? Или с СУБД год за два идет?

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

AVK>Плохая у тебя память. навскидку, к примеру, вспоминается добавление в Дельфи специальной поддержки СОМ — интерфейсы, делегация, позднее связывание, автоматичный рефкаунтинг.

Это средства общего назначения, а не ДСЛ. Интерфейсы полезны и без КОМ-а. Так что это очередное неверное понимания сути термина.

AVK>Да и foreach в шарпе по сути эдакий мини DSL.

Это ближе к теме, но на полноценный ДСЛ не тянет. Опять же нет самой области. Понятно, что и такие фичи языка можно делать макросами. Но мне кажется Синклер говорил немного о другом.

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

VD>Синклер, тебе ведь где-то 30 лет?! Ты что с СУБД с 10 лет работаешь? Или с СУБД год за два идет?
Если быть точным, то с 12.

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

VD>>А теперь попытайся с помощью своего кода загрузить тот самый Ёксель, открыть им файл с диска и распечатать страничку.

V>Ты сомневаешься, что тот класс можно доработать так, чтобы он ком загружать умел?

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

Пойми, никто не спорит, что для конкретной задачи можно обойтись динамикой. Но ты же отрицаешь метапрограммирование как класс, а не для одной задачи?

VD>>Да. Ну, тогда второе задание. Попробуй напиши аналог макроса lazy. Причем, чтобы он тоже статически типизированным был.
VD>>Не вышло? Ну, будем ждать от МС когда они соизволят включить аналог в Шарп.

V>Влад, это очень похоже на онанизм. Вот сколько я занимаюсь программированием, ни разу не видел SRS в котором бы был FR "Lazy computations". С его бы это?

Кто такие SRS и FR?

А то что ты чего-то не видел — это конечно аргумент. Эдак если бы ты не видел скажем C# или LINQ, то это конечно был бы повод для того чтобы безопеляционно заявить, что это все игрушки и настоящим прораммистам-прикладникам они не нужны.

VD>>Ну, а зачем тебе тогда макросы отсиживать?
VD>>Пользуйся макросами известных производителей и ищи воркэраунды когда в них находятся ошибки. Будет такая же ситуация как сейчас с C#.
V>Влад, к сожалению, иногда, код пишется более чем одним человеком, причем далеко не самым идеальным. Хуже того, частенько код уже написан и повлиять на него ты можешь только переписав заново.

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

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

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

V>В данном случае я писал конкретно про макрос late, а не про макросы вообще.

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

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

VD>>А что понимается под Александреску? Его книга? Его библиотека Локи? Или приемы метапрограммирования которые он предложил?

V>Приемы. Я сам по молодости после его прочтения с трехэтажными шаблонами на код бросался. Ужас...

А тебе не кажется, что ты путаешь причину и следствие?
Трехэтажными шаблоны становятся из-за того, что их применяют не по назначению. Ну, не разрабатывались они для метапрограммирвания (МП). МП удается реализовать на них в следствии побочного эффекта (полноты по Тьюрингу).

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

VD>>Только давай сравним это дело с нагромождением кода который появился бы в проекте если небыло бы макросов.
V>Откуда такой вывод, что если нет макросов, то обязательно есть нагромождение кода?

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

VD>>Итак. Видит некто задачу реализованную на макросах. Встает вопрос, а действительно ли нужно было применять макросы? Если ответ — да, то реализация на макросах будет во много раз проще и понятнее нежели закат солнца вручную который будет при ручном исполнении.

V>Не факт. Все зависит от того, откуда руки растут у писавшего.

Факт. Но он доступен только тем кто не отрицает все что выходит за рамки того к чему его приучили.

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

VD>>В общем, макрос — это инструмент. Он не самоцель. Он позволяет сделать решение проще, а стало быть решить больше задач или решить более сложную задачу.

V>Адресная арифметика — тоже инструмент.

Вот только вряд ли она тебе поможет в решении твоих задач. В отличии от...

VD>>Ну, да. Конечно если мы вместо внятного решения на макросах увидим невнятную гору кода
V>Невнятная гора кода лучше, чем невнятная гора макросов.

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

VD>>написанную недоучкой которая средства метапрограммирования освоить не смогла, то все станет в сто раз проще.
V>Я сам был когда-то таким "недоучкой" на С++ и удивлялся, чего это старшие товариши в штыки воспринимали мое гениальное метапрограммирование. Теперь вот понял.

Ну, надеюсь, что ты еще не дорос до потолка своего развития.

VD>>Очень хочется напомнить, что суть статьи никакого отношения к макросам не имеет (и тем-более эволюции живых существ). Прошу всех спорщиков еще раз прочесть название статьи и саму статью. А то вы ушли в какие-то потаённые дебри сознания и спорите ради спора. Причем многие из вас спорят о том, что никогда в жизни не пробовали. Другими словами ваши спор не очем и не зачем.

V>ИМХО, Майкрософт считает, что "наворачивание" языка сейчас менее целесообразно, чем развитие прикладных направлений фреймворка.

А мое мнение — кто-то сотворил себе кумира и слепо отвергает все что исходит не от этого кумира.

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

G>...Скажем, она финансирует работы связанные с Хаскелем, F#, и много еще чего.

Nemerle тоже был создан в раках проекта живущего на деньги МС Ресерч.
Вот и не ясно почему в МС не применяют технологии опробованные в F# и Nemerle (хотя бы квази-цитирование) хотя бы для внутренней разработки.
Этому то что мешает?

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

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

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

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

Лиспо попросту не поднялся. А решать задачи ИИ ему как раз и позволила развитая макросистема.

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


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

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

VD>Это средства общего назначения, а не ДСЛ.

В случае Дельфи это не так.

VD> Интерфейсы полезны и без КОМ-а.

Это если их не надо обязательно тт IUnknown наследовать.

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

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

В теории убеждаются посредством предсказанных ею новых явлений.
Когда астрономы обнаружили новые планеты или спутники планет — они двигались как предсказал Коперник.
Астрономия от Аристотеля вообще ничего не предсказывала, она просто описывала как движутся по небу
уже известные планеты, и ничего не могла сообщить о причинах этого движения (акромя "по воле богов").

Как ты понимаешь, с предсказаниями от Гартнера — история похожая. Он не может предсказать или предположить,
отчего те или иные технологии появляются и какова будет скорость их прогресса, когда пора выходить
с новой технологией, когда ещё рано или уже поздно. Он просто описывает процесс социодинамики вокруг
новых технологий. По форме кривой хайпа прикидывает как этот хайп будет дальше развиваться. ХАЙП,
а не технология!
Я не говорю, что у него плохие "предсказания". С точки зрения заработка денег в краткосрочной
перспективе — хайп важне самой технологии. Более того, у него целая фирма, которая на этом
специализируется, они обрабатывают огромный объём статистического материала, и в краткосрочной
перспективе могут сделать очень даже точный прогноз, поскольку учитывают много факторов.
Вот только его предсказания идут из статистики, а не от понимания сути происходящего.
Если с астрономией это бы сработало (планеты всё время движутся по одним и тем-же орбитам),
то в отношении жизненного цикла конкретной технологии — у него большие шансы ошибиться.
Потому как их судьба уникальна.

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

VD>Меня удивляет две вещи.
VD>1. Зачем так громко отрицать нужность того, что потом все же оказывается очевидным и нужным?

Вариант A. Отрицанием занимаются одни люди, а реализацией потом -- другие.

Вариант B. Люди с трудом отказываются от своих убеждений. Если человек сегодня убежден в том, что в языке L фича M не нужна, то он будет отстаивать свою точку зрения до тех пор, пока не накопиться достаточное (для этого человека) количество фактов, для того, чтобы сам этот человек изменил свою точку зрения. Особенно в условиях, когда у него другой работы достаточно.

Сюда так же нужно добавить и влияние спроса на некоторую фичу. Взять тот же DLR. В начале разработки .NET вряд ли кто-нибудь из разработчиков .NET мог подумать, что через 6-8 лет популярность динамических языков вырастет на столько, что потребуется создавать DLR для того, чтобы удовлетворить спрос на динамику в .NET.

Вариант C. "Мое кунг-фу сильнее твоего кунг-фу". Образно говоря, пока кто-то с успехом громит своих соперников с помощью отлично поставленных 2-3х ударов, он может громогласно заявлять о преимуществе своей техники, пока он не получит несколько раз приличных тумаков от людей, владеющей более сложной техникой. Говоря о программировании: Java-программисты долгое время работали с нетипизированными контейнерами и были всем довольны до тех пор, пока не стало очевидно, что шаблоны в C++ и дженерики в C# гораздо более удобны. Аналогично вывод типов в C# -- без него вполне себе обходились в C#1 и C#2 до тех пор, пока не стало ясно, что без вывода типов тот же LINQ нормально не получится (на точности последней аналогии не настаиваю, т.к. не являюсь .NET-чиком и располагаю только самой поверхностной информацией).

Вариант D. "Сейчас есть гораздо более важные проблемы, поэтому отвалите все с вашими идеями". После выхода продукта, которым начинает пользоваться большое количество самых разных пользователей, на разработчиков продуктов сваливается огромное количество совершенно разных пожалений, претензий, требований и баг-репортов. Со всем этим объемом нужно что-то делать. Кроме того, у разработчиков еще остался свой вагон и маленькая тележка идей, которые не нашли своего воплощения в текущей версии из-за различных факторов (сроки, бюджеты, недостаток информации и пр.). Со всем этим нужно справиться и уложиться в какие-то приемлимые сроки выпуска следующей версии продукта. А тут еще фанаты фичи M вопят во весь голос: "Нет-нет-нет-нет, мы хотим сегодня!", перекрикивая фанатов фич N, O, P, R, S, T и тд. Поэтому кому-то в ответ _нужно_ сказать "fuck off".


Это только то, что сразу вспомнилось. А так же возможна любая комбинация из вышеизложенных вариантов.

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

Практика (D, Nice, Scala, Groovy, Spec#) показывает, что если кто-то хочет создать язык с передовыми фичами, то его не останавливает отсутствие возможностей метапрограммирования в оригинальном языке-родителе. Так же сомнительно, чтобы разработчикам тех же Java и C# было сложно ввести в язык ту или иную фичу (с технической точки зрения). Скорее здесь вопросы филосовского плана -- новая фича должна вписываться в идеологию языка, быть востребованна широкими массами пользователей и/или решать задачу, которая иными средствами не решается. Решение таких филосовских вопросов требует гораздо больше времени и сил, чем реализация той или иной фичи. И, как мне представляется, наличие средств метапрограммирования в языке, которое позволяет сотням (тысячам) любителей экспериментов с новыми языковыми конструкциями проверять какие-то свои идеи, ничем не помогает разработчикам оригинального языка с решением подобных философских вопросов. Может быть даже наоборот -- сейчас им не приходится разбираться с 20-тью различными реализациями макросов late, присланных "доброжелателями" для включения в новую версию языка.

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

C>значит пример просто выбран не корректно

Т.е. гнобить на основании того, что человек якобы религиозный фанатик, можно?

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

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

Глобальная цель developer division — обеспечить максимально возможное количество пользователей каждой очередной версии средств разработки. И впихивание всего подряд, что потенциально может быть полезным вряд ли этому поспособствует. Энтузиастов, вроде тебя, которым надо скорее и побольше, их совсем немного в процентном отношении. Основная же масса до сих пор не переварила фичи C# 3.0.

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

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

VD>Лиспо попросту не поднялся. А решать задачи ИИ ему как раз и позволила развитая макросистема.

Поднялся, почему нет. Но на короткое время, вместе с американской программой СОИ. Их минобороны начало вбухивать немерянные средства в системы исскуственного интеллекта. Что такое минобороны США для IT. Йордан говорил, что минобороны это примерно половина всей заказной разработки софта в Штатах была . Поэтому, неудивительно, что многие инженеры отметились на оборонке.

Инженеры должны были срочно осваивать бюджеты, и они взяли за основу Лисп, как проверенное средство для задач ИИ (а не потому, что там макросистема была хорошая). Это был пик популярности лиспа — появились даже специализированные лисп-процессоры. Однако, после Рейгана "звездные войны", подкосившие экономику, были свернуты, и вместе с интересом заказчика, пропал хайп исскуственного интеллекта. А вместе с ним — и Лисп.

Теперь о макросредствах. Я расскажу еще про одну маркетинговую штуковину, учтя которую, и думая в терминах которой, ты сможешь объяснить многие явления. Это понятия "косвенная конкуренция" и "замещающие технологии". По сути, эти позволит вникнуть в суть конкуренции и в детали этого процесса. Вот, смотри. Чтобы что-то кому-то "продать", в прямом или образном смысле, ты должен удовлетворить его вполне конкретную потребность. То есть, потребность должна как минимум существовать. Однако, внимание! — если она существует, то она уже удовлетворяется каким-то образом СЕЙЧАС, даже в том случае, если у тебя продукт или технология не имеет прямых конкурентов и аналогов. Поэтому, зачастую получается так, что выходя с новым продуктом, тебе приходится конкурировать с набором существенно более дешевых "замещающих технологий".

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

Теперь точно о макросредствах. Видишь-ли какая штука, отдельного спроса на макросредства — почти нет, он очень небольшой. Есть спрос на отдельные задачи, который удовлетворяется "по месту", так называемыми "замещающими технологиями". Хочешь писать компиляторы? Вот тебе специализированный макрогенератор. Хочешь с базами данных работать удобно? Вот тебе LINQ. Соответственно, получается, что спрос на собственно макросредства сейчас почти мизерный. И, в отличии от ксерокса, широкая общественность не видит расширения юзкейсов реальной жизни сравнительно с "замещающими технологиями".

Одним из таких killing use-cases, может являться методология разработки бизнес-систем, полагающаяся на макросредства. Она уже появилась — это Model Driven Development, и разнообразные Language-oriented programming. Вот расхайпят этот подход как следует — глядишь, мы и увидим макросредства в мэйнстриме.

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

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

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

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

Я вообще-то тебе не "справку о крутости" даю и не аргументы, а провожу ликвидацию безграмотности, рассказав, что такое Гартнер и заодно — IDC. Теперь ты это знаешь, не так ли? Облажался ты действительно до крайности смешно — в первой же фразе, ну что ж, это урок всем нам .

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

Ну откуда тебе знать, чем лучше пользоваться, если ты от маркетинга далек до такой степени, как Аристотель до луны? Объяснить тебе, почему я не собираюсь тратить с тобой время на увлекательную дискуссию о хайп-циклах? Изволь.

Знаешь, чем маркетинг отличается от болтовни? Тем, что маркетолог в конечном счете всегда оперирует цифрами — объмами рыков, тенденциями, сегментациями, и пр. Все свои выводы он обязан перевести в цифры. Получить эти цифры урайне тяжело, не имея никакой базы, и предоставлением этой базы занимаются специализированные агенства, которые снабжают отделы маркетинга большинства компаний точными данными и аналитикой. Без таких данным маркетолог как без рук — и поэтому, подписка на Gartner есть почти у всех крупных компаний. Любой человек, прямо или косвенно имеющий отношение к теме, знает что такое Гартнер и IDC, ну, примерно, как любой программист слышал о компании Microsoft, даже если пишет под линукс или мак.

Итак, ты в довольно экзотической форме, одной фразой, сразу дал мне понять, что до маркетинга от твоей работы как до Аристотеля, и никакой практики ты в этом деле никогда не имел. Хорошо, не вопрос. Не знаешь, не понятно — спроси по человечески. Я одного не пойму — зачем ты с такой бездонной глубиной знаний спорить-то лезешь, а? Ты ведь, на минуточку, не зная что такое Гартнер, самоутвердится только что пытался за его счет крупнейшего профессионального хайтечного аналитического агенства. Самому не смешно? Тебе еще аргументы какие-нибудь нужны? Осень наступила чтоли, не пойму?

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

M>Смешно разговаривать с людьми, которые вместо аргументов приносят справку о крутости авторитета

Еще более смешно разговаривать с людьми, которые в качестве аргуметов ничего кроме аналогий не приводят, ИМХО.

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

ЧВV>Через некоторое время появляются слухи о планах по включению этой возможности в один из продуктов Microsoft, и где-то через 1-3 года продукт, реализующий эту возможность, появляется у нас на компьютерах.

Некоторые объяснения и возражения здесь

Автор: nikov
Дата: 08.09.08

.

G>Я расскажу еще про одну маркетинговую штуковину, учтя которую, и думая в терминах которой, ты сможешь объяснить многие явления. Это понятия "косвенная конкуренция" и "замещающие технологии".

Забыл сказать. Понятие косвенной конкуренции на самом деле шире, чем замещающие технологии. Это хорошо видно на следующем примере. Телевидение, интернет, и компьютерные игры — казалось бы не являются конкурентами друг другу. Однако, они конкурируют за общий ресурс — за свободное время пользователя, которое он тратит на развлечения, являясь косвенными конкурентами. Это не абстракция, это суровая реальность, с которой приходится иметь дело компаниям, чей бизнес связан с телевидением — они наблюдают вполне реальное сокращение своей базы и "смотрибености" каналов по мере увеличения проникновения интернета. От него же, родимого, начинают страдать телефонные операторы. Поэтому, как реакция в конкурентной борьбе, во всем мире наблюдается строгая тенденция слияния трех сервисов — интернет, телевидение, и телефония. Эта тенденция получила название TriplePlay. Пример? Обратите внимание на Корбину.

Еще примеры неочевидной конкуренции. Технологии IP-телевидения сейчас по всему миру потихоньку "убивают" видеопрокаты. Причина — сервисы "видео по запросу". Что делать видеопрокатам? Перспективы отвратительные, чем больше будет расти доля абонентов IPTV, тем хуже будет прокатам, будь я прокатом, я бы убил себя об стену, стал переходить на прокат дисков BlueRay, думал, как открывать сервисы интернет-киосков, вроде iTunes Store, и ввел бы просто продажу дисков. Кстати, идея продукта, на который должен быть спрос с положительной динамикой — движок сайта видеопроката (video on demand).

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

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

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

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

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

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

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

Согласен, но я не то имел ввиду, просто недостаточно четко выразился. Я имел ввиду, что конкретно Майкрософт скорее вводит в язык фичи, которые полезны для фреймворка/средств разработки чем придумывает некую абстрактную фичу языка, а потом постепенно начинает эту фичу использовать во фреймворке. Пример последнего — дженерики, пример первого — всё остальное. Хотя, может я чего и упустил (например анонимные делегаты).