Судьба новых идей, или почему прогресс идет так медленно - Философия программирования

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

V>я тоже много сокрушался по поводу отсутствия того или иного вида синтаксического сахара. Юзинга нет или еще чего — как люди вообще могут писать программы на яве, я понять не мог. Но вот когда дело дошло до решения конкретных проблем предметной области, проблемы языка сразу стали несущественными. 95% mainstream-программистов сильно начхать на эти "приятные мелочи", ибо они "живут" в своей предметной области и почти все проблемы, с которыми им приходится сталкиваться — это проблемы предметной области для которых возможный выигрыш от "приятные мелочей" ничтожен. Прикладной программист не бьется над проблемой, как вызвать метод: через рефлексию, или динамический сахар? Он бьется скорее над поиском: какой метод вызвать, когда вызвать, с какими параметрами вызвать и что делать с результатом. Как видишь, в решении реальных проблем, с которыми сталкиваются прикладные программисты, синтаксический сахар помогает слабо, ибо он лишь помогает ответить на вопрос "Как сделать?", но он ни на сантиметр не приближает к ответу на "Что делать?". А основополагающий вопрос — это именно второй. Вот лично мне почти плевать на эти новые языковые фичи, так как они помогают лишь в решении мелких тактических задачек, которые и раньше решались совершенно без сколько-нибудь существенных трудозатрат.

Отрадно осознавать, что не перевелись еще на Руси разумные люди!
Надобно твердо осознавать, что к прогрессу и всяким финтифлюшкам новамодным с осторожностью великой относиться положено.
Ибо кто может разуметь разницу между путешествием с помощью самолета реактивнаго и лошади ломовой, когда впереди всего — принять решение, куда двигаться надлежит? Ибо путь в тьму шагов зачинается с однаго шага.
Вдругорядь, кака разница между емелием новамодным и проверенным годами почтовым голубем? Поелику мудрый человек разумеет: главное то, чего в грамоте написано.
Вместо того, чтобы невозбранно напедалить осемь экранов на басике православном, как у нас, программистов индустриальнаго типа междусобойно положено, несерьезные программисты используют бесовские фичи сишарпов третьих, из сотонинского хаскеля (Господи прости) понатянутых. Небывать тому! Ясно же, что инфернальныя функциональныя языки одному только врагу рода человеческого и понятны!

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

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

VD>То есть эволюцию двигают в перед корпорации вроде MS?

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

Например, когда появилось радио — экосистема (набор технологий, привычки людей, развитая инфраструктура) передачи данных
уже существовала — почта, телеграф и т.п. Для радио нашлась маргинальная ниша — передача данных между кораблями в океане.
Просто повезло, что радиоволны отражаются от ионосферы, и за счёт этого огибают землю, и такая связь стала возможной.
Радио было по всем статьям хуже имеющихся технологий, но оно развивалось, поскольку было место (маргинальное) где
старые технологии вообще не работали. Потом с развитием радио (технологии, инфраструктуры и пр.) его стали использовать
всё шире и шире. Теперь радио-технологии почти полностью вытеснили старые телеграфы/телеграммы и пр.

Так как нас интересуют компиляторы и языки программирования, то в применении к ним — для нового языка программирования
нужна такая ниша, где старые технологии (языки) не справляются. Тогда он будет развиваться. Тогда вокруг него
сформируется экосистема (в том числе и люди, знающие этот язык), которая и сможет бороться со старыми языками.
Если вы для nemerle не найдёте такой маргинальной ниши — проект засохнет. Найдёте — будет жить и развиваться,
как бы его не давили.

Это очень обобщённое и неполное описание. В живой природе есть множество примеров развития и борьбы самых разных
вариантов экосистем. Если хочешь действительно понять как это происходит и как нужно действовать для развития
твоей новой технологии (nemerle) — почитай книжку Еськова "История Земли и жизни на ней" (кажется так).
Только помни, что книга — не инструкция, а повод для размышлений.

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

[.......................................................]

Вот в Майкрософте наверное такая же ситуация — им говорят, давайте фичу добавим, полезно! А у них завязывается флейм об экосистемах на несколько месяцев. Когда мозговая диарея исчерпает свои ресурсы, кого-то вдруг осенит — а чего все началось-то? И тут они вспоминают о той полезной фиче...

Статья:
Судьба новых идей, или почему прогресс идет так медленно

Авторы:
Чистяков Влад (VladD2)

Аннотация:
Вот уже который раз встречаю преинтереснейшую картину. Эта картина настолько задевает меня, что я решил поделиться с вами своими впечатлениями. Картина эта выглядит так. Где-то в глубине народных масс появляется некая неординарная идея. Эта идея теми или иными путями доходит до ушей в Microsoft и представители Microsoft бодрым голосом заявляют, что мол, это идея бредовая/вредная/бесполезная, и вроде бы тихо про нее забывают. В лучшем случае просто не следует никакой реакции. Проходит время, и вдруг появляется массированный пиар этой самой идеи, исходящий из недр Microsoft. Далее начинается массированная поддержка этой идеи в блогах. Через некоторое время появляются слухи о планах по включению этой возможности в один из продуктов Microsoft, и где-то через 1-3 года продукт, реализующий эту возможность, появляется у нас на компьютерах.

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

ЧВV>Конечно, неплохо, что массовый пользователь языков программирования – mainstream-программист – через несколько лет сможет воспользоваться этими приятными мелочами, но непонятно, почему для реализации таких мелочей требуется вместо одного-двух месяцев 5-6 лет.

Знаешь, Влад, когда я учил яву, я тоже много сокрушался по поводу отсутствия того или иного вида синтаксического сахара. Юзинга нет или еще чего — как люди вообще могут писать программы на яве, я понять не мог. Но вот когда дело дошло до решения конкретных проблем предметной области, проблемы языка сразу стали несущественными. 95% mainstream-программистов сильно начхать на эти "приятные мелочи", ибо они "живут" в своей предметной области и почти все проблемы, с которыми им приходится сталкиваться — это проблемы предметной области для которых возможный выигрыш от "приятные мелочей" ничтожен. Прикладной программист не бьется над проблемой, как вызвать метод: через рефлексию, или динамический сахар? Он бьется скорее над поиском: какой метод вызвать, когда вызвать, с какими параметрами вызвать и что делать с результатом. Как видишь, в решении реальных проблем, с которыми сталкиваются прикладные программисты, синтаксический сахар помогает слабо, ибо он лишь помогает ответить на вопрос "Как сделать?", но он ни на сантиметр не приближает к ответу на "Что делать?". А основополагающий вопрос — это именно второй. Вот лично мне почти плевать на эти новые языковые фичи, так как они помогают лишь в решении мелких тактических задачек, которые и раньше решались совершенно без сколько-нибудь существенных трудозатрат.

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

E>А в теории эволюции, к которой вы так апеллируете, есть упоминания о тупиковых ветвях развития видов? И что она говорит о видах, которые заняли какую-то узкую нишу (например, по определенной кормовой базе) и не способны выжить вне ее рамок (как панды или коалы, которые не могут существовать без бамбука и эвкалиптов)?

Как я написал Владу — книга, это не инструкция, а повод для размышлений. Теории — тоже

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

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

Другой вид развития — адаптация. Это когда у нас есть система (в нашем случае — технология) которая может адаптироваться
(изменяться) к конкретным условиям. Не навсегда — когда условия изменятся, то и система изменится. В отличие от лягушек,
которым нужна и вода и земля, адаптивный вид животным легко мог-бы жить и в воде не требуя земли, и на земле не требуя
водоёмов — не эволюционирую, а подгоняя свой организм или окружающую среду под текущие условия.
Яркий пример адаптации — это, конечно, человек. Живёт от экватора до полюсов, адаптируясь, а не специализируясь.

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

Мета-программирование — по определению адаптивная технология. И следовательно, для неё справедливы все указанные
выше достоинства и недостатки. В частности, она "дороже", чем специализированные технологии. Она должна пройти
долгий путь развития, прежде чем "цена" использования мета-программирования станет сравнимой с "ценой" использования
специализированных технологий программирования. И её путь развития — это адаптация, а не специализация.
Нельзя быть "немного адаптивной", как нельзя быть "немножко беременной".
Влад меня попрекает тем, что я отказался от текста. А мне что, было легко принять это решение?
Текстовые технологии хорошо развиты, 90% проблем которые я имею в SymADE — связаны с отказом от
текстового представления программ. Но я понимаю, что другого выхода нет — надо двигаться в сторону
всё большей адаптивности, надо использовать и развивать свои сильные стороны.

И за счёт намного большей адаптивности SymADE (адаптивности отображения и редактирования программ,
адаптивности внутреннего представления — определения новых семантических понятий, а не просто
макросы которые трансформируют код в предопределённый набор семантических понятий) — SymADE может
занять те маргинальные ниши, которые Nemerle занять в принципе не может.
Я вчера честно думал несколько часов — в какую нишу можно приткнуть Nemerle? И не придумал.
Может Влад придумает. А может и нет. Он меня даже спросил — читал ли я его статью. Конечно читал.
А он не понимает, какое отношение мои комментарии имеют к его статье. Значит он не владеет этим
способом мышления, значит он тем более не сможет придумать куда приткнуть Nemerle. Разве только
случайно повезёт.

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

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

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

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

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

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

S>>Почему фиг? Поставишь брекпоинт, как обычно, и посмотришь через Watch или Immediate, что происходит.
V>Падает где-то в коде, сгенерированным макросом.

Вы открыли мне глаза на саму суть жизни. Очевидно, что компилятор — это зло. Когда же наконец программисты прозреют и осознают, что во всех их ошибках виноват компилятор. Компилятор написан Гашиш Кумаром, он сделает из нашего прекрасного челкода ужасный, насквозь ошибочный и изъеденый багами машкод. А потом, мы будем годами просматривать нули и еденички, пытаясь разобраться со всеми ошибками, которые добавил компилятор. Думаю, что очевидно то, что давно уже пора отказаться от этого ужаса и писать сразу в машкодах (понятных и очевидных, разумеется. Что и не удивительно, никакой декомпозиции, никакой абстракции и прочих средств смутить неокрепший ум).

V>Наверное, это от того, что у всех разный опыт. Мне несколько раз приходилось занимаься реанимацией проектов, разрабатывавшихся и проваленных индусами. Дак вот, ответственно заявляю: Слава БОГУ, что у этих индусов не было макросов!

Я конечно понимаю, что лучшая аргументация критики это полное отсутвие опыта работы с тем, что критикуешь. Естественно, если все так плохо без X, то как ужасно бы было с X! Словами это описать невозможно.
Правда, есть и другие способы вывести суждение из опыта, например, это, кажется, называется, индукция из простой последовательности. 100% ужасных индус-триальных проектов разработано с использованием компиляторов.
Quod erat demonstrandum: compiler considered harmful!

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

Здравствуйте, Чистяков Влад (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#, и много еще чего.

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

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

S>>Вот этот момент мне непонятен. Что есть "хитросплетение макросов"? Вот прикинь, он открывает сейчас код странички, а там какие-то мутные using(), foreach() и т.п.
S>>Неужто для отладки он должен понять, во что раскрывается паттерн foreach, потом скомпилировать это в уме в MSIL, потом отджиттить, и только после этого исправить ошибку?
VE>Да, если в реализации foreach и using есть ошибки.

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

S>>Да, в коде макроса lazy происходят мутнейшие операции с AST. Тем не менее, выполнять их не нужно. Потому что сразу же виден источник ошибки: вставили новый столбец, и надо исправить диапазон на B1:B12.
S>>Вот это и есть очевидный код.
VE>Всё хорошо до тех пор, пока все макросы работают безошибочно.
VE>Но если бы так все писали, было бы счастье. А вот если в написанный кем-то давно макрос закралась ошибка...

В чем принципиальная разница с любой другой библиотекой?

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

Что вы понимаете под простотой? Что проще: дифоператор ротора или страница мути из сложений вычитаний и производных?
Что проще, функция, или n-раз повторенный копипаст? И чем один копипаст лучше другого копипаста?

VE>что исправлять тупой как пробка код проще, чем тот, который перековыривает AST,

Да уж, трудно представить себе код более сложный, чем работа с AST — это же просто rocket science какой-то. Разумеется, ни в одной библиотеке функций решающих более сложные задачи, чем трансформации деревьев просто не бывает.

VE>использует такие фишки языка, о которых дай бог 5-10 спецов в курсе.

Это смелая оценка. Когда в языке нет таких фишек — в курсе 0 спецов. Вот только так когда-то было со всеми фишками. Остается только удивлятся, что хоть одна фишка существует, учитывая, что ничего страшнее нового и неизвестного нет.

VE>Так что хорошим аргументом было бы, если бы реализация макроса lazy была бы проста как пробка; хотя может так оно и есть?

Конечно, лучше — это реализация на каждое использование позднего связывания. Вива ля копипаст! Куда уж проще, правда?

Вот и prVovik встроил в язык мини динамический DSL. От макроса он отличается тем, что DSL у него не компилируемый, а интерпретируемый — в чем преимущество мне не понятно. Также автор отмечает облегчение при отладке. Это мне тоже не понять. Неужто отлаживать код на DSL вместе с интерпретатором этого DSL каждый раз это удобнее, чем отлаживать сгенерированный код?
Где бенефиты-то?

Вообще, управляемый код с самого начала, практически, позволяет реализовывать нелокальные преобразования. Почему рагнарек все никак не наступает?

Может, как в случае с шуткой про монады — все дело в названии? Ведь я что-то не припомню страшной паники после появления Emit-а (или в 2002 была?) или опасений, что индусы, вооружившись expression tree, разрушат цивилизацию?

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

Мне кажется, единственный способ прекратить это безобразие — устроить Влада в Microsoft

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

IT>Тупая часть стада пойдёт туда, куда его погонят. Это так, но речь сейчас вовсе не об этом. Речь о погонщиках стада, а у них всегда есть выбор куда его гнать.

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

P.S. В последнее время гонка технологий в программировании всё больше напоминает мне типичную рекламу для домохозяек типичного общества потребления. "Новое, лучшее, купи, скачай..." Так что непонятно, кого ещё называть "тупым стадом".

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

VD>Вообще-то я говорил не о языке, а о добавлении новых фич в существующие языки. Скажм С++ немогут доработать вот уже 10 лет. C# меняется раз в 3 года по чайной ложке.

Ну это такая экосистема. Она организована вокруг фиксированного синтаксиса и семантики.
Это даёт то преимущество, что можно написать другой компилятор, можно написать другой анализатор кода — и они будут работать. Потому как следуют стандарту.
И этих обслуживающих программ, и этих программистов воспитанных изучать фиксированные языки — много. Почти любое изменение только ухудшит ситуацию для этих
программ и этих людей. Оно сделает устаревшими все эти программы и эти знания людей. Поэтому их "развивают" так, чтоб эти ухудшения были минимальными —
минимально переписать компилятор/IDE/рантайм, минимально добавить необходимых навыков программистам. Не говоря уже о таких фундаментальных проблемах:
— новые фичи быстро начинают противоречить друг другу и устаревшим фичам языка
— сложность коммпиляторов/IDE/рантайма возрастает непропорционально улучшениям (улучшения чувствуют единицы, те, кому новые фичи нужны, а усложняются компиляторы для всех).

Альтернативный подход — мета-программирование, заключется в том, чтоб нужные фичи добавить по мере необходимости, добавить для себя, для своего проекта,
не затрагивая стандарт. А в идеале — и возможность убрать старые фичи, которые мешают (и не нужны для данного проекта). У этого подхода есть свои недостатки
и свои достоинства. И главное — он не развит, как экосистема. Мало хороших средств разработки, мало людей так программирующих и т.п. А неразвит он
по той причине, что нет такой ниши у него, где он был-бы жизненно необходим, где без него нельзя обойтись. Точнее, такие маргинальные ниши есть, но
на них мало обращают внимание, всех тянет в мэйнстрим, а там такая конкуренция с имеющимися экосистемами, что мета-программированию ничего там не светит.
Есть и ещё проблема — в подавляющем числе случаев мета-программирование становится реально нужным для мега-проектов, когда уже много кода написано и
проект упирается в невозможность его дальнейшего развития (из-за чрезмерно возросшей сложности). Но к этому времени так-же невозможно переписать проект
по новой, на новом языке, изначально поддерживающем мета-программирование.

Вот простой пример из эволюции жизни на Земле. Травка (степь) вытеснила леса. Она это сделала потому, что давала себя есть травоядным животным. И при
этом не погибала (до 60% биомассы травы можно съесть без малейшего ущерба для неё). А деревья, когда они только маленькие росточки — если с них съесть
листочки, то они погибнут. Они не могут позволить себя есть. Вот экосистема из травы и травоядных животных и вытеснила леса (в тех районах земли, где
хорошие условия для роста травы). Хотя степь не лучше леса, просто она "лучше" его на одном небольшом этапе — когда дерево ещё ростом с травинку.
Так же и в программировании — сейчас такой buzzword как "динамические скриптовые языки" только потому гудит, что они лучше на начальном этапе, когда
надо наваять простую программку на несколько страниц. Но этого оказалось достаточно — особенно для создания сайтов-однодневок в интернете и т.п.
И поэтому-же мета-программирование буксует — оно не нужно, пока проекты небольшие, а когда уже большие — то его туда не прилепить.

В общем, тут можно долго рассказывать, и ещё больше можно размышлять самому. Лично я для SymADE уже выстроил беспроигрышную стратегию.
Он будет развиваться в своей маргинальной нише, будет независимо ни от чего — потому как в этой нише у него нет конкурентов.
А когда вокруг него сформируется экосистема, когда он станет достаточно зрелым — вот тут он в мэйнстрим и попадёт.
И не важно займёт это 10 лет или 15, это произойдёт неприменно, потому как его будут толкать неодолимые силы.
Законы природы нельзя отменить, но можно или безуспешно пытаться пробить их лбом, или использовать в своих целях.
Но для начала их надо знать

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

Очепятка.

Много лет назад, когда .NET только-только появился, многие задавились вопросом, почему в C# нет позднего связывания

Что-то я много лет назад, задавленных вопросом не видел.

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

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

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

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

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

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

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

Пример — ксерокс. Мой любимый пример

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

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

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

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

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

VD>Извини, ты статью-то читал?

Я прочитал, а потом и перечитал. Но какой-то стержневой мысли выделить не смог. Зачем вообще эта статья была написана?

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>

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

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

ИНИЦИАТИВА СНИЗУ.
(пьеса)

Действующие лица:

Paul Hudak
John Hughes
Simon Peyton Jones
Philip Wadler — глыбы, матерые человечищи.

Ходоки — заклинатели змей из Бангалора.

Сцена 1.

Октябрь 87-го. Hudak, Hughes, SPJ, Wadler пьют чай и обсуждают планы грядущей функциональной революции.

SPJ

Так дело не пойдет, товарищи! Нам архиважна свежая струя пролетарских реквестов!

Сцена 2.

Входят ходоки.

1-й ходок

Народу нужен чистый, ленивый язык!

SPJ

Правильно мыслите, товарищи!

Hudak

Совершенно верно!

2-й ходок

Реквестируем монад и стрелок. Да побольше!

Hughes, Wadler (хором)

Сделаем!

3-й ходок

И не забудьте сделать так, чтобы ad-hoc полиморфизм был несколько менее ad-hoc.

Wadler

А это идея...

З А H А В Е С.

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

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

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

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

M>

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

, которого они цитируют.

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

.

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

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

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

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

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

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

Самому не смешно? Тебе еще аргументы какие-нибудь нужны? Осень наступила чтоли, не пойму?

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

M> Ты со сложными проектами работал? С какими, приведи пример, и получишь понятный тебе ответ.

Начинать лучше сразу с того,э сколько у тебя самого сантиметров.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

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

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

M>Да, но есть сам процесс, есть причины его вызвавшие и правила по которым он развивается. У него есть разные проявления, его можно анализировать, его можно рассматривать с разных точек зрения. Говоря о развитии технологии, мы можем его рассматривать с точки зрения его положения на кривой хайпа, а можем его рассматривать с точки зрения его жизненного цикла (вроде цикла — становление, экспансия, стагнация, рецессия), и пр. Но если ты хочешь быть эффективен — тебе нужно знать причины, а не следствия. Не в том смысле, что следствия нам не интересны, а в том смысле, что влияя или зная причины — мы можем вывести, предсказать, повлиять на следствия. Это как стратегия и тактика. Очень важно вести себя правильно тактически, но выиграет тот, у кого правильная стратегия (при условии, конечно, что тактически они ведут себя правильно).

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

Mistake 1: Failing to spend enough time researching the business idea to see if it's viable. "This is really the most important mistake of all. They say 9 [out] of 10 entrepreneurs fail because they're undercapitalized or have the wrong people. I say 9 [out] of 10 people fail because their original concept is not viable. They want to be in business so much that they often don't do the work they need to do ahead of time, so everything they do is doomed. They can be very talented, do everything else right, and fail because they have ideas that are flawed."

Недостаточно много времени уделено исследованию бизнес-идеи с целью понять, насколько она жизнеспособна. "Это действительно самая важная ошибка из всех. Говорит — 9 из 10 предпринимателей не достигли успеха из-за недостатка финансирования или плохой команды. Я скажу — 9 из 10 не достигли успеха потому, что их изначальная концепция не была жизнеспособна. Они до такой степени хотят быть в бизнесе, что часто не делают работы, которую они должны провести в первую очередь, и в результате все что они делают проваливается. Они могут быть очень талантливы, и делать все остальное правильно, и провалиться только потому, что их идеи содержат изъяны.

Mistake 2: Miscalculating market size, timing, ease of entry and potential market share. "Most new entrepreneurs get very excited over an idea and don't look for the truth about how many people will want to buy it. They put together financial projections as part of a presentation to pump up their investors. They say, 'The market size is 50 million people that could use this product, and if I could only sell to 2 percent of them, I'd be selling a million pieces.' But 2 percent of a market is a lot. Most products sell way less than 1 percent."

Неверная оценка объема рынка, времени, простоты вхождения и потенциальной доли рынка. "Большая часть начинающих предпринимателей с восторгом относятся к своей идее, и не обращают внимание на правду о том, насколько много людей захотят ее купить. Они вкладывают свои финансовые прогнозы в презентацию с целью привлечь инвесторов. Они говорят "объем рынка — 50 миллионов человек, которые могут использовать данный продукт, и если я смогу продать двум процентам из них, я продам миллион экземпляров". Но два процента рынка — это в действительности очень много. Большинство продуктов продается гораздо меньше, чем одному проценту.

Mistake 3: Underestimating financial requirements and timing. "They set their financial requirements based on Mistake 1, and they go ahead and make a commitment to this much office space and this many computers, and hire a vice president of sales, and so on. Before they know it, based on sales projections that were wrong to start with, they have created costs that require those projections to be met. So they run out of money."

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

Mistake 4: Overprojecting sales volume and timing. "They have already miscalculated the size of the market. Now they overproject their portion of it. They often say 'There are 200 million homes, and I need to sell [to] x number of them.' When you break it down, though, a much smaller number of those are really sales prospects. That makes it impossible to make their sales projections."

Mistake 5: Making cost projections that are too low. "Their cost projections are always too low. Part of the reason is that they project much higher sales. There are also unknown reasons that always come out that usually make costs higher than planned. So on top of everything, their margins are now lower."

Mistake 6: Hiring too many people and spending too much on offices and facilities. "Now you have lower sales, higher costs and too much overhead. These are the things that you see every day in companies that fail. And they all grow out of that first mistake: failing to research the size and viability of the opportunity."

Mistake 7: Lacking a contingency plan for a shortfall in expectations. "Even if you're realistic in your estimates to start, there are things that happen when you start a new business. Your sales ideas may be no good; bank rates may go up; there may be a shipping strike. These aren't the result of poor planning, but they happen. More often than not, entrepreneurs just feel that something will come along when they need it. They don't have contingency plans for it not working out at the size and time they want."

Mistake 8: Bringing in unnecessary partners. "There are certain partners you need. For instance, you often need money, so you're going to need money partners. But too many times, the guy with the idea takes on all his friends as partners. Many people don't provide strategic advantages and don't warrant ownership. But they're all going to get 25 percent of the company. It's totally unnecessary, and it's a mistake. Before people are made partners, they have to earn it."

Mistake 9: Hiring for convenience rather than skill requirements. "In my first business or two, I hired relatives. It was easy to do, but in many cases, they were the wrong people [for the job]. And it's hard to fire people, especially if they're relatives or friends. More time needs to be spent handpicking people based on skill requirements. You really need super-skilled people who can wear more than one hat. It just bogs you down when you hire people who can't do the job."

Mistake 10: Neglecting to manage the entire company as a whole. "You see this happen all the time. They'll spend half their time doing something that represents 5 percent of their business. You have to have a view of your whole company. But too often, the person running it loses that view. They get involved in a part, and they don't manage the whole. Whether I do this product or that product, whether I hire somebody, [I consider] how they [will] fit long term and short term in the big picture. Constantly try to see your big picture."

Mistake 11: Accepting that it's "not possible" too easily rather than finding a way. "I had an engineer who was a very good engineer, but with every toy we developed, he would say, 'You can't do it that way.' I had to be careful not to accept this too easily. I had to look further. If you're an entrepreneur, you're going to break new ground. A lot of people are going to say it's not possible. You can't accept that too easily. A good entrepreneur is going to find a way."

Mistake 12: Focusing too much on sales volume and company size rather than profit. "Too much of your management is often based on volume and size. So many entrepreneurs want to say 'I have a company that's this big, with this many people, this many square feet of space, and this much sales.' It's too much [emphasis] on how fast and big you can build a business rather than how much profit it can make. Bankers and investors don't like this. Entrepreneurs are so into creating and building, but they also have to learn to become good [businesspeople]."

Mistake 13: Seeking confirmation of your actions rather than seeking the truth. "This often happens: You want to do something, so you talk about it with people who work for you. You talk to [your] family and friends. But you're only looking for confirmation; you're not looking for the truth. You're looking for somebody to tell you you're right. But the truth always comes out. So we [test] our products, and we listen to what [the testers] say. We give much more value to the truth than to people saying what we're doing is great."

Mistake 14: Lacking simplicity in your vision. "Many entrepreneurs go in too many directions at once and do not execute anything well. Rather than focusing on doing everything right to sell to their biggest markets, they divide the attention of their people and their time, trying to do too many things at [one time]. Then their main product isn't done properly because they're doing so many different things. They have an idea and say they're going to sell it to Wal-Mart. Then they say they're going to sell to [the] Home Shopping Network. And then the gift market looks good. And so on."

Mistake 15: Lacking clarity of your long-term aim and business purpose. "You should have an idea of what your long-term aim is. It doesn't mean that won't change, but when you aim an arrow, you have to be aiming at a target. This [concept will] often come up when people ask 'How do I pick a product?' The answer depends on what you're trying to do. If you're trying to [create] a billion-dollar company with this product, it may not have a chance. But if you're trying to make a $5 million company, it can work. Or if you're trying to create a company [in which] family members can be employed, it can work. Clarity of your business purpose is very important [but] is often not really part of the thought process."

Mistake 16: Lacking focus and identity. "This was written from the viewpoint of building the company as a valuable entity. The company itself is also a product. Too many companies try to go after too many targets at once and end up with a potpourri rather than a focused business entity with an identity. When you try to make a business, it's very important to maintain a focus and an identity. Don't let it become a potpourri, or it loses its power. For instance, you say, 'We're already selling to Kmart, so we might as well make a toy because Kmart buys toys.' If you do that, the company becomes weaker. A company needs to be focused on what it is. Then its power builds from that."

Mistake 17: Lacking an exit strategy. "Have an exit plan, and create your business to satisfy that plan. For instance, I am thinking I might run my new business for two years and then get out of it. I think it's an opportunity to make a tremendous amount of money for two years, but I'm not sure [whether] it's proprietary enough to stop the competition from getting in. So I'm in with an exit strategy of doing it for two years and then winding down. I won't commit to long-term leases, and after the first year, we'll start watching the marketplace very closely and start watching inventories.

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

OE>Насколько я понял Влада, его колбасит именно от последовательности "отрицание, замалчивание, пиар, реализация, популяризация"

В 1993-м нам препод по системному анализу рассказал, что с начала 20-го века наблюдалась картина вида: сначала появляются публикацию на какую-то тему, которая могла бы стать перспективной. Эти публикации либо не вызывали серьезного резонанса, либо же встречались в штыки. После чего информация на эту тему исчезала из публичного доступа вообще и на длительный срок. С очень простым объяснением -- прозорливые люди объясняли военным шишкам перспективность новых идей и недопустимость передачи информации о них потенциальным/реальным противникам. После чего информация (далеко не вся) становилась доступной широкой общественности уже в виде конечного продукта -- нового вида вооружений или готовой к продаже технологии. Причем происходило это во всем цивилизованном мире, не только в СССР или США (а наиболее сильно начало проявляться в Германии перед 2-ой мировой).

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

ЧВV>Вот уже который раз встречаю преинтереснейшую картину.

«Уважайте темпы развития других людей»

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

E>Я прочитал, а потом и перечитал. Но какой-то стержневой мысли выделить не смог.

Значит одно из двух. Или не смог понять, или не захотел понять.

E>Зачем вообще эта статья была написана?

Выражение мнения. Не расстраивайся. Это не все могут понять.

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

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

Эволюция имеет к обсуждаемому вопросу прямое отношение.

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

AVK>Без всяких граничных случаев. Вот буквально вчера переписал старый кусок с использованием фич 3 шарпа — вместо нескольких экранов кода получилось 25 строк большей частью декларативного кода. Думаю, не стоит объяснять, что в плане поддержки новый вариант на голову круче, хотя время начальой разработки на общем фоне некритично.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V>using() и foreach() стандартны.

V>это слишком смелое предположение.
Нет, не слишком. Вот, к примеру, есть страшная штука — вызов метода. И что, наверное код Джавахарлалов переполнен вызовами методов? Нет, там скорее будет наоборот, копи-пейст везде, всё в линейном стиле, и трюки вроде

for(i=0; i<param2.Count;i++)
{
  string firstName = param2[1];
  string firstName = param2[2];
}

S>>там нормальный код на читаемом языке.
V>Это не важно.
Как раз важно, потому что если код читаемый, то всё понятно. Если нечитаемый, то непонятно.

S>>А вот улучшить могут. Потому, что к примеру вместо лапши из вызовов IDispatch на две страницы написан банальный
S>>

lazy Workbook.Sheets[1].Range("A1:A12").Formatting.BackColor=Color.Green;

V>А других вариантов нет? Либо лапша на 2 страницы из вызовов IDispatch, либо макрос?
Ну, либо поддержка lazy встроенная в язык, как это сделано в Delphi. И, если не ошибаюсь, в VB.

V>Вот незадача, а мы не вставляли новый столбец, а оно всеравно падает

Причем на каких именно действиях падает — непонятно. Там бы брейкпоинт поставить, а фиг.
Почему фиг? Поставишь брекпоинт, как обычно, и посмотришь через Watch или Immediate, что происходит.
Ребята, все эти ужоснахи происходят от какой-то боязни всего. Любой инструмент для упрощения кода можно применять для его запутывания. Вот, к примеру, вызов процедуры — страшное оружие в опытных руках. Достаточно выбрать неудачные имена, попользовать ref параметры, сделать трактовку возвращаемых результатов понетривиальней и всё, приплызд. Никто потом не разберется.
Да одной арифметики хватит для того, чтобы всё запутать до нераспутываемости!

Вон nikov регулярно постит этюды про шарп любой версии, и неизменно ставит в тупик проверенных гуру. Что там было про "почитать документацию по языку программирования"?

.
Наверное, в жизни все эти вещи со страшной силой портят жызнь разработчиков, и бедные Анандхаривы бьются головой о клавиатуру в попытках разгадать, каким образом структурность результата List<int>.GetEnumerator() cломала их хоме паге? Нет? Не бьются? И с макрами не будут. Макру еще придумать и написать надо.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

V>Тут возможны два варианта использования DSL'я
V>Первый (для меня, наверное, самый важный) — это когда у нас есть некая система сама в себе, и мы выставляем наружу DSL для людей, не являщихся программистами, которые в понятных им терминах предметной области смогут описывать нужное им поведение. Например, бизнес-аналитик на чем-то более человечном и приземленным, нежели BPEL, описывает нужный ему бизнес-процесс и сам же его запускает.
Для меня это как раз маловажный вариант использования. Вся проблема любого ЯП — в том, что он формальный. Умение формализовать задачу из предметной области — редкое умение. Именно оно отличает программиста от непрограммиста, а не запись в трудовой книжке.
Поэтому реально важнее второй вариант: вместо того, чтобы отдать программирование в руки непрограммистов, лучше дать инструмент улучшения производительности труда программистам.

V>Второй вариант — это DSL для программистов. То есть когда прогаммисты сами для себя придумывают свои собственные новые языки программирования. По-этому, твой пример с Linq vs SQL+XPath не совсем в тему, так как это общеизвестные языки.
Что такое "общеизвестные языки"???
Пример как раз в тему. Пока ты его не поймешь, дальше двигаться в беседе не получится.
Поясню историю на пальцах, по шагам:
1. Обработка данных на стандартных языках общего назначения (см. напр. file of record в Паскале). Чудовищный кошмар: низкая производительность, низкая надежность. Очень плохая производительность труда программистов.
2. Берем специальный императивный язык для управления данными, встраиваем в него убогие возможности общего назначения (см. dBase, Сlipper). Чудовищный кошмар: низкая производительность, низкая надежность. Плохая производительность труда программистов.
3. Придумыаем специальный декларативный язык для управления данными, подразумевая принципиальное двуязычие разрабатываемой системы (SQL+*). Нормальный кошмар: высокая производительность, высокая надежность готовой системы. Приемлемая производительность труда программистов.
4. Встраиваем декларативные средства по управлению данными в императивный язык (Linq). Безграничный восторг: высокая производительность, высокая надежность, в том числе и при внесении изменений в систему, охренительная производительность труда программиста.
Как видим, отдельный DSL недостаточно хорошо нам помогаетю

V> А что касается дээселей, то тут можно вспомнить пример из жизни. Иногда, люди специально придумывают себе язык. Нпример, бейсболисты. Но у них есть на это существенные основания: 1) не надрывать горло; 2)держать план в тайне от соперников. Но в повседневной жизни люди обычно не придумывают новые языки, так как это усложняет общение.
Отличный пример. Только он про наоборот: в повседневной жизни люди всё время придумывают новые языки. Иногда время жизни этих языков ограничено временем совместно решаемой небольшим коллективом задачи; иногда язык формирует целый диалект профессионального сообщества.
Но при этом люди почти никогда не придумывают отдельных языков. Жаргон бесшовно встраивается в окружающий его язык "общего назначения". В противном случае его выразительность была бы чрезмерно ограничена.

V>Я не говорю, что макросы и метопрограммирование бесполезны. Я хочу сказать, что их значимость для прикладных программистов сильно переоценена некоторыми посетителями этого форума и именно по-этому они не понимают действия Майкрософта.
Я констатирую факт: значимость DSL для Майкрософт значительно выше, чем для тебя. При этом все их действия показывают, что именно встроенные в язык DSL считаются правильным медом(ТМ).

V>Хм.. Какой подход обобщить? Что ты имеешь ввиду?
Я имею в виду подход с встраиванием DSL в существующий язык общего назначения. Одно из возможных средств для этого — макросы и метапрограммирование.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

M>В том-то и дело, что при мета-программировании всю эту тучу проблем решать не нужно.

В свое время никто так и не ответил — кто будет дорабатывать под очередной макрос ReSharper. Все что удалось получить — дескать, Nemerle настолько крут, что решарпер ему нафик не нужен.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

Написал смешно, молодец!

Но только ты не понял, о чем я писал. Наверное, я недостаточно точно сформулировал мысль. Прогресс должен облегчать жизнь людей. Если человек вынужден использовать голубиную почту, а прогресс ему предлагает использовать электронные часы с хайтек кукушкой, чтобы отправлять голубей точно по расписанию, то это не очень хороший прогресс. Потому что проблема не в том, чтобы отправлять голубей точно по расписанию (можно и механическими часами обойтись), проблема в том, что голуби плохо письма доставляют. Nuzhny приводил очень хороший пример с математиком, который использует древний фортран. Очевидно, многие считают, что математик станет много счастливее, если пересядет на Nemerle. Но вот только математику не составляет труда реализовать алгоритм даже на убогом фортране, у него другая трудность: придумать алгоритм.

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

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

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

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

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

G>Представь себе некий процесс. В нем есть две составляющие, два разных аспекта ОДНОГО процесса, которые влияют друг на друга в обе стороны в равной степени. Замерив одну из них, ты с хорошей точностью оценишь и другую. Пример из психологии — любая испытываемая эмоция приводит к напряжению определенного паттерна мыжц человеческого тела. Значит ли это, что напряжение мыжц следствие? Нет. Потому, что исследования Лоуэна в свое время показали, что имеет место и 100% обратный эффект — напряжение определенного паттерна мыжц вызывает заданную эмоцию. Ну, что причина, а что следствие? А они не связаны этим отношением. Напряжение мыжц и эмоциональные переживания — два аспекта одного и того же ЕДИНОГО процесса.

Вот для того, чтоб повлиять или использовать этот ПРОЦЕСС и нужно знание ПРИЧИН. Скажем, для тех-же эмоций — есть информационная теория эмоций Симонова, которая описывает эмоции как отношение изменения информации к силе потребности. То есть описывает причины и условия возникновения эмоций. Пользуясь ею мы может понять что такое эти эмоции вообще, какова будет сила эмоций, как эмоции будут развиваться во времени. А активация различных отделов мозга, напряжение мышц, гормональный статус, изменение кожногальванического сопротивления — это уже разные аспекты того, как эмоции проявляются в нашем теле.

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

Вот посмотри на поведение камня. Как бы ты его не бросал, вверх, в сторону, вниз, сильно, слабо — он всё равно упадёт на землю, и будет падать по параболе. Это — закономерность на которую можно полагаться, проверенная веками. Я только одного не могу понять — как же тогда спутники летают?

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

Скажем, по аналогией с той-же билогией. Многоклеточность возникала много раз. Она могла завоевать доминирующее положение на миллиард лет раньше или на миллиард лет позже. Но совершенно точно можно было быть уверенным, что она завоюет доминирующее положение. Вполне возможно, что разум бы возник не у приматов, а у дельфинов или слонов, или вообще у головоногих. Это частности, с точки зрения эволюции, слепой случай. А то, что разум рано или поздно возник-бы — это закон развития, который не обойти.

G>Нет, не ясно, что не на вершине хайпа. Ты опять все сильно упрощаешь, и жизнь опять оказалась несколько сложнее. На разных этапах хайп-цикла действуют разные типы инвесторов, которые имеют разные exit strategy и стратегии управления активами, вот и все.

Да, ты прав, я слишком упростил. В конце концов, я не специалист по маркетингу.

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

Это я и имел в виду, когда говорил, что не стоит инвестировать на основе эффекта толпы.

G>Хайп-цикл никак не показывает тебе аспекта конкурентной борьбы, он отражает "жизненный цикл". Это во-первых. Что попало на этот график наносить нельзя, это второе. И третье. На кривую хайп-цикла наносят РЕЗУЛЬТАТ анализа, который (анализ) достаточно глубок и разносторонен. Точки на данной кривой — это не входные данные для анализа, это его результат.

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

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

G>Ты очень странно представляешь себе работу маркетологов. Они не боги, чтобы что-то шло по их желаниям. Их работа — анализировать тенденции, и делать прогнозы. У них есть свой инструментарий, и разумеется, хайтечные маркетологи очень хорошо разбираются в предмете. И главный предмет их работы — это то, что начисто игнорируешь ты. Это анализ СПРОСА и ПОТРЕБНОСТИ. Именно спрос на технологии и удовлетворение потребностей обеспечивает их популярность (в редких случаях спрос можно создать специально, зотя и такие случаи известны). А не выполнение каких-то там внутренних законов внутри этих технологий.

Я как раз говорю о тех случаях, когда этот спрос создаётся специально. Чтоб его создать — надо знать причины, внутренние движущие силы процесса. И тогда даже минимальное, но точное воздействие, может драматически изменить ситуацию для конкретного инвестора. В смысле зарабатывания им кучи бабла.
Это как лавина — когда она пошла, её уже никто контролировать не сможет. Она пойдёт как пойдёт, по своим законам. Но до того, как она пошла — можно или предупредить её, чтоб она пошла позже, или вызвать её искуственно с другими последствиями, или хотя-бы построить дом не там, где она пройдёт.
Так же и с новыми технологиями. Бесполезно спрашивать "почему прогресс идёт так медленно". Ну, спросить-то можно, года три назад я себе задал этот вопрос и получил ответ — "потому, что он идёт настолько-же неумолимо". Ничего кроме морального удовлетворения я от этого ответа не получил

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

Влад тоже хочет знать почему прогресс идёт так медленно, и тоже, очевидно, в применении к своей технологии (сиречь Nemerle, или в более общем варианте — мета-программировании). Но он ничего изменить в этом процессе не может — и даже не знает, то-ли лавина уже идёт, то-ли надо где-то камешек толкнуть чтоб пошла. И уж тем более не знает какой камешек надо толкать. Так и будет вопрошать в никуда.

G>Питон с Руби и PHP, кстати, которые ты помянул, давно уже в мэйнстриме, и свою нишу заняли. Это зрелые технологии, как и Java. А "динамические языки" просто нельзя наносить как точку на хайп, это не является сомостоятельной технологией, это собирательный термин.

"Давно" — это когда? Год-два назад?

"Динамические языки" — это самостоятельная технология. Ruby, PHP — это её представители. Тоже самостоятельные технологии. Матрёшка такая.
Равно как и радио — это самостоятельная технология. А радиопередачи, телевидение, беспроводные телефоны — это его представители, тоже самостоятельные, тоже матрёшка.
По карайней мере моя теория развития технологий позволяет их рассматривать в таком виде. Если кривая хайпа не позволяет — это её проблемы

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

С моей точки зрения — процесс социодинамики вокруг технологии — да, так идёт. На достаточно небольшом участке жизненного цикла технологии (впрочем, этот участок является наиболее интересным с точки зрения зарабатывания денег на ней). Но не процесс развития технологии как таковой. Видимо в этом месте мы не понимаем друг друга. И что метапрограммирвание "никому не нужно" в том виде, в котором оно существует — частично согласен. Но его можно сделать "нужным". И в силу ряда причин оно таким и станет лет через десять-пятнадцать-двадцать. От меня, от Влада, от тебя, от других обсуждающих эту проблему — зависит когда это произойдёт (через 10 или 20 лет), и какую форму приобретёт. Ну и кто заработает на этом деньги

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

V>Как показывает практика, поддерживаемость кода в основном зависит от программиста, который этот код пишет, а не от языка программирования

Моя практика показывает, что оно зависит и от того и от другого.

V> (если, конечно, не брать граничные случаи типа ассемблера)

Без всяких граничных случаев. Вот буквально вчера переписал старый кусок с использованием фич 3 шарпа — вместо нескольких экранов кода получилось 25 строк большей частью декларативного кода. Думаю, не стоит объяснять, что в плане поддержки новый вариант на голову круче, хотя время начальой разработки на общем фоне некритично.

... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>

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

M>Альтернативный подход — мета-программирование, заключется в том, чтоб нужные фичи добавить по мере необходимости, добавить для себя, для своего проекта, не затрагивая стандарт. А в идеале — и возможность убрать старые фичи, которые мешают (и не нужны для данного проекта). У этого подхода есть свои недостатки и свои достоинства. И главное — он не развит, как экосистема. Мало хороших средств разработки, мало людей так программирующих и т.п. А неразвит он
M>по той причине, что нет такой ниши у него, где он был-бы жизненно необходим, где без него нельзя обойтись. Точнее, такие маргинальные ниши есть, но на них мало обращают внимание, всех тянет в мэйнстрим, а там такая конкуренция с имеющимися экосистемами, что мета-программированию ничего там не светит. Есть и ещё проблема — в подавляющем числе случаев мета-программирование становится реально нужным для мега-проектов, когда уже много кода написано и
M>проект упирается в невозможность его дальнейшего развития (из-за чрезмерно возросшей сложности). Но к этому времени так-же невозможно переписать проект по новой, на новом языке, изначально поддерживающем мета-программирование.

Думаю что в случае с MS картина выглядит иначе. У этой компании столько ресурсов, что она сама способна сформировать требуемую экосистему "на заказ". Как только MS решит добавить в очередную версию c#-а возможности метапрограммирования, тут же в бой вступит армия pr-менеджеров, евангелистов и т.д., будут выпущены книги и учебные пособия, блоги запестрят описанием вкусностей новой версии c#-а и премами их использования, появятся и специалисты и проекты, категорически не могущие обойтись без метапрограммирования. Примерно так оно и было во время появления .net

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

VE>Он спросил, какое отношение язык имеет к эволюции живой природы, т.е. к его примеру.
VE>А ты пытаешься сказать, что аналогию провести нельзя, потому что 2+2 = 4. Так какое отношение этот факт имеет к его примеру? Как он его опровергает?
VE>Вот я тоже выше спросил, чем язык мешает или как он что-то опровргает?

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

Но строить доказательную базу на этом просто глупо.

Неясность изложения обычно происходит от путаницы в мыслях.

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

WH>>Имея четко определенный фундамент всегда можно однозначно определить что делает код.
M>Только для достаточно простой системы.
Для абсолютно любой.
Если модель системы не противоричива то мы всегда можем однозначно интерпритировать код системы.
Размер не имеет значения.

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

WH>>В твоей системе это сделать невозможно.
M>Почему? У меня вообще нет системы. У меня среда разработки программ. IDE. Что ты в неё вложишь — то ты и получишь. Вложишь противоречивый набор семантических понятий — так и будет.
А твой движек который оперирует семантическими понятиями это что?

WH>>Просто по тому что один фанатик С++ напишет работу с XML. Другой фанатик схемы напишет работу с HTTP.
WH>>А прикладной программист не сможет использовать эти две подсистемы в своей программе.
M>А сейчас может?
Если все трое пушут на жабе то да.
Ибо плюсовику придется забыть про деструкторы, а любителю схемы про континюэйшены.
При всех недостатках жабы она имеет убийственное преимущество перед твоей системой: непротиворичивая модель

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

ЧВV>Статья:
ЧВV>Судьба новых идей, или почему прогресс идет так медленно

ЧВV>Авторы:
ЧВV> Чистяков Влад (VladD2)

ЧВV>Аннотация:
ЧВV>Вот уже который раз встречаю преинтереснейшую картину. Эта картина настолько задевает меня, что я решил поделиться с вами своими впечатлениями. Картина эта выглядит так. Где-то в глубине народных масс появляется некая неординарная идея. Эта идея теми или иными путями доходит до ушей в Microsoft и представители Microsoft бодрым голосом заявляют, что мол, это идея бредовая/вредная/бесполезная, и вроде бы тихо про нее забывают. В лучшем случае просто не следует никакой реакции. Проходит время, и вдруг появляется массированный пиар этой самой идеи, исходящий из недр Microsoft. Далее начинается массированная поддержка этой идеи в блогах. Через некоторое время появляются слухи о планах по включению этой возможности в один из продуктов Microsoft, и где-то через 1-3 года продукт, реализующий эту возможность, появляется у нас на компьютерах.

Влад, у меня есть новая идея. Хотите? Пронаблюдайте за ее судьбой.

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

VE>Законы этого мира в этом мире абсолютны. Их можно только изучать, и использовать.

Ересь. Или неправильное использование понятий.

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

V>95% mainstream-программистов сильно начхать на эти "приятные мелочи"...

Тупая часть стада пойдёт туда, куда его погонят. Это так, но речь сейчас вовсе не об этом. Речь о погонщиках стада, а у них всегда есть выбор куда его гнать.

Неясность изложения обычно происходит от путаницы в мыслях.

O>>Влад, у меня есть новая идея. Хотите? Пронаблюдайте за ее судьбой.

VD>Хочу, если она действительно нова.

Она полностью описана здесь: http://www.rsdn.ru/forum/message/3064178.aspx, http://www.rsdn.ru/forum/message/3067144.aspx, http://vingrad.ru/blogs/dorozhko/category/udalennyiy-obmen-znaniyami/

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

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

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

V>>>Но только ты не понял, о чем я писал.

VD>>Сдается мне, что непонимашь тут все же ты.

V>Не понимаю что?

Ты не понял, что ты написал. А Влад и остальные поняли

Ну у них это не впервой, впрочем

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

S>Тем не менее, на моей памяти это чуть ли не первый раз, когда в язык общего назначения добавляют такие штуки.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

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

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

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

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

AVK>В свое время никто так и не ответил — кто будет дорабатывать под очередной макрос ReSharper.

А что там дорабатывать?

Неясность изложения обычно происходит от путаницы в мыслях.

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

IT>Но если бы не линк, то они вообще бы не далались. Разве не так?

Не знаю. Что толку гадать? Что имеем, то и имеем.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

M>Очевидно, дорабатывать его надо тем, кто его хочет использовать.

Все, не продано.

M>Тут либо доработка сложна, либо бенефит получится незначительный.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

IT>>Но если бы не линк, то они вообще бы не далались. Разве не так?

AVK>Не знаю. Что толку гадать? Что имеем, то и имеем.

Да тут и гадать нечего. Достаточно здарого смысла, чтобы понять, что функциональные фишки в C# — это побочный эффект добавления Linq. С одной стороны это хорошо, т.к. мы эти фишки имеем. С другой, надеяться на добавление новых стоит только, если они будут частью чего-то большего.

Неясность изложения обычно происходит от путаницы в мыслях.

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

M>>>Очевидно, дорабатывать его надо тем, кто его хочет использовать.
AVK>>Все, не продано.

M>А что, кто-то покупал?

Мы о коммерческом программировании еще говорим?

M> Ты готов заплатить денег разработчикам Nemerle?

В текущем состоянии — нет.

M>Какие проекты — такие и инструменты. Если твоим проектам

Сколько сантиметров?

M>Будет намного дешевле написать "плагин", который твой десяток мегабайт превратит в три-четыре,

Это миф.

M>Скажем, SymADE проектируется так, что эта проблема в нём будет решена.

Скажем, SymADE вообще никуда не годится.

M>Или за счёт чего так поднялся AOP?

С чего ты взял, что АОП куда то поднялся? Все что от него осталось — инструментирвание прикладного кода. А для этого самого инструментирования очень часто компайл-тайм технологии не подходжят в принципе, потому что делать его надо не при компиляции, а при деплойменте, поверх бинарников.

... << RSDN@Home 1.2.0 alpha 4 rev. 1096>>

G>>17 самых распространенных ошибок стартапщиков от профессионального успешного стартапщика.

E>Спасибо, было очень интересно почитать (а ссылочка на первоисточник есть?).
17 Mistakes Start-ups Make
или просто поиск типа такого

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

G>Linq
G>Language Integrated Query:[11] "from, where, select" context-sensitive keywords allowing queries across SQL, XML, collections, and more. These are treated as keywords in the LINQ context, but their addition won't break existing variables named from, where, or select.

Ну с этим все ясно. Далее:

G>Object initializers
G>Customer c = new Customer(); c.Name = "James";
G>can be written
G>Customer c = new Customer { Name="James" };

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

G>Collection initializers
G>MyList list = new MyList(); list.Add(1); list.Add(2); can be written as MyList list = new MyList { 1, 2 }; (assuming that MyList implements System.Collections.IEnumerable and has a public Add method[12])

Вопрос, конечно спорный, но без этой фичи не напишешь код, типа: from i in new List<int>(){1, 2, 3, 4} where i % 2 == 0 select i;

G>Anonymous types
G>var x = new { Name = "James" }

Нужны, чтобы из Ling возвращать результат.

G>Local variable type inference
G>Local variable type inference: var x = "hello"; is interchangeable with string x = "hello";. More than just syntactic sugar, this feature is required for the declaration of anonymous typed variables.

Без этой фичи невозможно использовать Linq.

G>Lambda expressions
G>Lambda expressions: listOfFoo.Where(delegate(Foo x) { return x.Size > 10; }) can be written listOfFoo.Where(x => x.Size > 10);
G>Compiler-inferred translation of Lambda expressions to either strongly-typed function delegates or strongly-typed expression trees.

Без этой фичи невозможно использовать Linq.

G>Automatic properties
G>The compiler will automatically generate a private instance variable and the appropriate getter and setter given code such as: public string Name { get; private set; }

Кодогенерация.

G>Extension methods
G>Extension methods (adding methods to classes by including the this keyword in the first parameter of a method on another static class)

Без этого было бы невозможно создавать пользовательские операции в Linq

G>Partial methods
G>Allow codegenerators to generate method declarations as extension points that are only included in the source code compilation if someone actually implements it in another portion of a partial class.[13]

Кодогенерация.

P.S.: ох, чувствую сейчас флейм начнется

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

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

.

M>Я знаю ЧТО? Что это крутой мужик, с извесной фирмой? Это хоть как-то отменяет тот факт, что его hype методика базируется на последствиях, а не причинах? Чем отличаются последствия от причин я тебе уже писал.

Ну хорошо, давай поговорим. Опустим то, что ты мне писал об отличиях причин отследствий (я, как человек с высшим математическим образованием, в курсе этой тонкой разницы), и остановимся для начала на том, в чем ты делаешь ошибку с самого начала. Ты не прав в том, что она базируется на последствиях. Хайп — является не только следствием, но и причиной, это необходимый и важный элемент процесса внедрения инноваций. Допустим, я придумал крутую штуку. Если я о ней не пишу, и она не вызывает бурного обсуждения в публикациях, как ты (а главное — широкая общественность, и инвесторы) о ней узнают? С другой стороны — если я пишу, а хайпа нет — это означает ровно одно. Людям это не интересно, и это не затрагивает никаких значимых потребностей.

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

Выглядит это примерно так:

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

Хотя, учет этой закономерности может сильно помогать в ряде случаев. Например:
http://www.gartner.com/DisplayDocument?id=507779
Подписки на Gartner у тебя разумеется нет, и поэтому посмотреть ты можешь только оглавление.

M>Ты мне хоть один аргумент приведи, кроме крутизны и бездонности знаний тов.Гартнера.
M>Возьми его методику на вооружение и выведи из неё — куда будет идти прогресс, какие идеи так и останутся без надобности, а какие будут востребованы. Скажи когда нужна будет та или иная технология (ведь нужно прийти с ней "вовремя", не так-ли?).
M>Главное — что hype методика может ПРЕДСКАЗАТЬ, а не "объяснить" ПОСТФАКТУМ.

Вот, теперь ты знаешь, что такое "методика hype". Вторая твоя ошибка, на которой ты основываешь свои претензии, состояла в том, что это никакая не "методика", которой надо следовать, и будет тебе счастье, а всего лишь одна из наблюдаемых закономерностей, которую надо учитывать и на нее полагаться. Более подробно разницу между "методикой" и "закономерностью" объяснять не надо?

Здравствуйте, 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>задача тривиальна. Если не знаешь — то задолбаешься понимать.

И не говори!

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

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

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

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

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

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

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

ЧВV>Аннотация:
ЧВV>Вот уже который раз встречаю преинтереснейшую картину. Эта картина настолько задевает меня, что я решил поделиться с вами своими впечатлениями. Картина эта выглядит так. Где-то в глубине народных масс появляется некая неординарная идея. Эта идея теми или иными путями доходит до ушей в Microsoft и представители Microsoft бодрым голосом заявляют, что мол, это идея бредовая/вредная/бесполезная, и вроде бы тихо про нее забывают. В лучшем случае просто не следует никакой реакции. Проходит время, и вдруг появляется массированный пиар этой самой идеи, исходящий из недр Microsoft. Далее начинается массированная поддержка этой идеи в блогах. Через некоторое время появляются слухи о планах по включению этой возможности в один из продуктов Microsoft, и где-то через 1-3 года продукт, реализующий эту возможность, появляется у нас на компьютерах.

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

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

S>Думаю что в случае с MS картина выглядит иначе. У этой компании столько ресурсов, что она сама способна сформировать требуемую экосистему "на заказ". Как только MS решит добавить в очередную версию c#-а возможности метапрограммирования, тут же в бой вступит армия pr-менеджеров, евангелистов и т.д., будут выпущены книги и учебные пособия, блоги запестрят описанием вкусностей новой версии c#-а и премами их использования, появятся и специалисты и проекты, категорически не могущие обойтись без метапрограммирования. Примерно так оно и было во время появления .net

Не вижу, почему "иначе". Именно так, как я и написал.
У MS уже есть своя экосистема. Называется MS Windows.
Другие компании, пусть даже столь-же крупные, не всегда имеют свою экосистему. Ну, IBM имеет экосистему "для большого бизнеса".
А такие как Sun, HP — нет. Что-то мелкое есть у Apple, Sony.
Понимаешь, вся хохма в том, что далеко не всегда армия pr-щиков и баснословные рекламные компании могут привести к
созданию экосистемы. Для неё должа существовать объективная ниша. Вот Sun пытался продвинуть Java — её изначально
создавали для embedded девайсов. А выстрелила она в web-е, как запускался applet-ов. Правда, оказалась слишком
неудобной — пока не было конкурентов, апплеты писали. А теперь их полностью вытеснили jscript и flash.
Яве сильно повезло — пока она сидела в своей нише для web-апплетиков, она как технология успела сформироваться.
И когда её вытесняли, она была достаточно развита, чтоб побороться за другие места. И заняла две странных
ниши — web-allocation сервер (для которых её и не предназначали) и мобилки (они как раз стали достаточно
мощными, чтоб вместить яву). Это как пример того, что развитие происходит по своим законам, и в них деньги
решают далеко не всё. Деньги могут помочь, но не более. Если физически ниша занята другой экосистемой, или
приходит лучшая сформировавшаяся экосистема — никакие деньги не помогут.

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

M>Законы эволюции на кривой кобыле не объедешь. Они объективны.

Законы эволюции были объеханы примерно 30-50 тыщ лет назад на кобыле, называемой речь. Обмен информацией по сравнению с генами ускорился на многие порядки, в результате чего наш вид очень быстро стал доминировать на планете. Если бы всё развивалось по объективным законам, то мы бы ещё вряд ли доросли до изобретения колеса.

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

Неясность изложения обычно происходит от путаницы в мыслях.

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

M>>Ты понимаешь под словом "эволюция" только эволюцию живой природы? Напрасно.

IT>Я понимаю под словом эволюция эволюцию. Ты использовал примеры эволюции живой природы, я привёл тебе ещё один.

Пример эволюции живой природы? Какое к ней имеет отношение язык? Эволюции "цивилизации" (человеческой культуры)?
Какое она имеет отношение к живой природе?

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

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

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

IT>Не, ты не понимаешь. Какая разница как ходить по луне, в скафандре или без? Муравьи ни через 10k, ни через 10kkk лет не смогут ходить по луне хоть с приспособлениями, хоть без них.
А вы не сможете совокупляться каждые 10 секунд, хоть с приспособлениями, хоть без, и что?

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

IT>Главное, что в основу всего этого положен не эволюционный путь развития, а совершенно другой. Благодаря речи человек смог вырваться из оков эволюции и сразу же стал доминировать: съел всех мамонтов, сжёг Австралию, приручил животных, построил города, создал машины, ядерное оружие и интернет, полетел в космос. Без развития речи мы смогли воспользоваться всем этим ещё очень не скоро.
А благодаря быстрым ногам гепард может бегать со скоростью 110км/ч.
А вы — благодаря созданным машинам. Какая разница?
Скажете, что разница в том, что можно сделать машину ещё быстрее? Согласен, но это средство. Наше — оказалось лучше остальных.

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

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

IT>Эволюционно передача знаний и опыта происходит с помощью генов. Для того, чтобы позитивные знания, с точки зрения прогрессирования определённого вида, надёжно закрепились в генах нужны десятки/сотни/тысячи поколений.

Вот я и говорю — ты под словом "эволюция" понимаешь только биологическую эволюцию.
Я под словом "эволюция" понимаю процесс развития вообще.

IT>С помощью речи знания передаются не только от поколения к поколению, но и внутри одного поколения. Соответсвенно развитие вида начинает идти на порядки быстрее и уже отличным от эволиции способам.

Это тоже эволюция, это тоже процесс развития.

Прочитай хоть определение терминов, прежде чем спорить о предмете
http://ru.wikipedia.org/wiki/Эволюция

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

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

Кстати, всегда было интересно, как в США запрещают публикции по определённой тематике. Ведь среда там типа либеральнее.

http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V> 95% mainstream-программистов сильно начхать на эти "приятные мелочи", ибо они "живут" в своей предметной области

Очень зря, кстати. А то потом прочитать и понять, что же это написано никак нельзя.

http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

V>> 95% mainstream-программистов сильно начхать на эти "приятные мелочи", ибо они "живут" в своей предметной области

ANS>Очень зря, кстати. А то потом прочитать и понять, что же это написано никак нельзя.

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

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

IT>Тупая часть стада пойдёт туда, куда его погонят. Это так, но речь сейчас вовсе не об этом. Речь о погонщиках стада, а у них всегда есть выбор куда его гнать.

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

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

FR>Закон Ома это частный случай, уравнения Максвелла уже будут работать на любых частотах

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>

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

V>Количество строк кода не является критерием поддерживаемости.

Является. Хотя, конечно, критерий этот далеко не единственный и даже не самый важный.

... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>

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

V>Количество строк кода не является критерием поддерживаемости. Вообще, поддерживаемость — это сложное понятие, которое включает в себя противоречивые критерии. С одной стороны "лаконичность", а с другой "очевидность". Лаконичность часто противоречит "очевидности". В общем, это созвучно древним флеймам из С++, что лучше: написать простенький цикл руками, или использовать алгоритмы из STL. Первый вариант "очевидный", а второй "лаконичный". Какой из них "правильный" — сказать сложно. Короче, это я к тому, что уменьшение количества строк кода еще не означает однозначное улучшение поддерживаемости. Соответствующий пример привести не сложно. Думаю, ты и сам можешь

Это очень левый пример.
В С++ использование STL ужасно и связано с появлением кучи мусора.
В более правильных языках мусора нет.

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

V>Тут Майкросовту предъявляют претензии, что он медленно реализует языковые фичи в шарпе. Но зато они сделали WF, WCF, которые решают реальные проблемы прикладных программистов, которые намного важнее, чем отсутствие какого-нибудь паттерн-матчинга.

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

Фреймворк сам по себе — зависит от языка, от платформы.
Именно платформа определяет — как будет реализован фреймворк/api.
Будет в платформе паттерн-мэтчинг, будут замыкания — и фреймворк будет реализован совершенно иначе.
И эта иная реализация может кардинально улучшить использование фреймворка.
И пока ты будешь учиться решать задачи мышекликанием как в дельфях, или подобным "высокоинтеллектуальным" методом —
тебе будет хватать имеющихся фрейворков. А когда тебе надо будет написать действительно сложный алгоритм,
вот тут тебе и захочется "новомодных" фич.

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

WH>Это очень левый пример.
WH>В С++ использование STL ужасно и связано с появлением кучи мусора.
WH>В более правильных языках мусора нет.

Дело не в мусоре. К мусору привыкаешь и перестаешь замечать, как не замечаешь баннеры с рекламой на веб-страницах.

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

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

Создания стены и кирпича в этой стене.

СУВ, Aikin

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

V>Но только ты не понял, о чем я писал.

Сдается мне, что непонимашь тут все же ты.

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

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

V>>Но только ты не понял, о чем я писал.

VD>Сдается мне, что непонимашь тут все же ты.

Не понимаю что?

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

V>Тем не мениее флеймы на эту тему возникали(ют) постоянно, и вовсе не от незнания STL. Хорошо, возьми вместо STL что-нибудь из Александреску. Компактно? Компактно! Очевидно? Ну разве что после поллитры. Хотя ладно, тут опять можно съехать на том, что С++ кривой. Давай представим, что настало счастливое будущее. Nemerle покорил мир. Некто Jagadheeswaran получает задание пофиксить баг на web-страничке. Документации, естественно, нет. Людей, которые это писали, конечно, тоже. Открывает он код странички — а там хитросплетение макросов.
Вот этот момент мне непонятен. Что есть "хитросплетение макросов"? Вот прикинь, он открывает сейчас код странички, а там какие-то мутные using(), foreach() и т.п.
Неужто для отладки он должен понять, во что раскрывается паттерн foreach, потом скомпилировать это в уме в MSIL, потом отджиттить, и только после этого исправить ошибку?

V>Что тут делается — непонятно, поэтому Jagadheeswaran заглядывает в код макроса.
Скорее всего, если код не написан другим Джагадхисвараном, там нормальный код на читаемом языке. Если код написан в стиле репортов для Бэст, то конечно там разобраться невозможно. И дело не в макросах, а в том, что все идентификаторы имеют имена типа clk4, o, oo, ooo и прочий мусор. При этом половина выражений посчитана просто так и нигде не используется, выполняется большое количество избыточных проверок, и прочее. Тут никакие макросы ситуацию не ухудшат.
А вот улучшить могут. Потому, что к примеру вместо лапши из вызовов IDispatch на две страницы написан банальный

lazy Workbook.Sheets[1].Range("A1:A12").Formatting.BackColor=Color.Green;

V>В коде макроса выполяются какие-то мутные операции с AST.
Да, в коде макроса lazy происходят мутнейшие операции с AST. Тем не менее, выполнять их не нужно. Потому что сразу же виден источник ошибки: вставили новый столбец, и надо исправить диапазон на B1:B12.
Вот это и есть очевидный код.
V>В итоге он должен понять, что тут происходит с AST, потом вернуться обратно, выполнить в уме преобразование AST, представить, какой будет результирующая программа и, наконец, найти в этой виртуальной программе ошибку. Про отладку я вообще молчу. Вот это и есть неочевидный код.

... << RSDN@Home 1.2.0 alpha rev. 677>>

lazy Workbook.Sheets[1].Range("A1:A12").Formatting.BackColor=Color.Green;

V>>В коде макроса выполяются какие-то мутные операции с AST.
S>Да, в коде макроса lazy происходят мутнейшие операции с AST. Тем не менее, выполнять их не нужно. Потому что сразу же виден источник ошибки: вставили новый столбец, и надо исправить диапазон на B1:B12.
S>Вот это и есть очевидный код.
Всё хорошо до тех пор, пока все макросы работают безошибочно.
Но если бы так все писали, было бы счастье. А вот если в написанный кем-то давно макрос закралась ошибка...

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

Так что хорошим аргументом было бы, если бы реализация макроса lazy была бы проста как пробка; хотя может так оно и есть?

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

FR>>Закон Ома это частный случай, уравнения Максвелла уже будут работать на любых частотах

AVK>В качестве лирического отступления, просьба не считать это попыткой аргументировать ту или иную позицию.
AVK>Уравнения Максвелла вообще не описывают ток в проводниках, они описывают поведение электромагнитных волн в вакууме, а не движение свободных электронов (и других носителей заряда) через кристаллическую решетку. Закон Ома обобщается до полного закона Ома, закона Ома в комплексной форме для синусоидального тока, дифуров при переходных процессах, потом до различных теорий навроде теории Друде.
AVK>Искажения простых закономерностей закона Ома на высоких частотах объясняется инерционностью носителей зарядов,а не уравнениями Максвелла.

В качестве лирического отступления, просьба не считать это попыткой аргументировать ту или иную позицию.

Мужики, а какое это все отношение к теме-то имеет? Это ведь обсуждение конкретной статьи?

ЗЫ

Обожаю этот форум.

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

V> Я показал, что это неверно.
Ты всего лишь показал, что на turing-complete языке запрограммировать можно всё, что угодно.

С тем же успехом можно было обобщить твои рассуждения на, скажем, генерик-типы.
Я бы говорил, что программиста есть ровно три варианта, а ты бы говорил, что List object'ов вполне приемлемый результат.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

V>>Первый (для меня, наверное, самый важный) — это когда у нас есть некая система сама в себе, и мы выставляем наружу DSL для людей, не являщихся программистами, которые в понятных им терминах предметной области смогут описывать нужное им поведение. Например, бизнес-аналитик на чем-то более человечном и приземленным, нежели BPEL, описывает нужный ему бизнес-процесс и сам же его запускает.
S>Для меня это как раз маловажный вариант использования. Вся проблема любого ЯП — в том, что он формальный. Умение формализовать задачу из предметной области — редкое умение. Именно оно отличает программиста от непрограммиста, а не запись в трудовой книжке.

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

V>>Второй вариант — это DSL для программистов. То есть когда прогаммисты сами для себя придумывают свои собственные новые языки программирования. По-этому, твой пример с Linq vs SQL+XPath не совсем в тему, так как это общеизвестные языки.
S>Что такое "общеизвестные языки"???

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

S>4. Встраиваем декларативные средства по управлению данными в императивный язык (Linq). Безграничный восторг: высокая производительность, высокая надежность, в том числе и при внесении изменений в систему, охренительная производительность труда программиста.
S>Как видим, отдельный DSL недостаточно хорошо нам помогаетю

Напомню, что DSL расшифровывается, как Domain Specific Language. Linq — это язык запросов общего назначения и его домен полностью покрывается доменом языка программирования общего назначения. Linq не несет с собой никакого специфического домена в язык программирования общего назначения, по-этому он не является DSL-ем. А вот если бы Майкрософт встроил бы в си-шарп язык описания бизнес-процессов, то вот это уже был бы встроенный DSL.

S>Отличный пример. Только он про наоборот: в повседневной жизни люди всё время придумывают новые языки. Иногда время жизни этих языков ограничено временем совместно решаемой небольшим коллективом задачи; иногда язык формирует целый диалект профессионального сообщества.
S>Но при этом люди почти никогда не придумывают отдельных языков. Жаргон бесшовно встраивается в окружающий его язык "общего назначения". В противном случае его выразительность была бы чрезмерно ограничена.

Профессиональные сообщества придумывают новые слова, а не новый синтаксис.

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

V>Знаешь, когда я пересаживался с С++ на первый сишарп, тоже по началу долго плевался на отсутствие типизированных коллекций. Но реально особых проблем с этим не было. Вообще не помню, чтобы InvalidCastException было проблемой. Потом, когда появились джинерики, я не могу сказать, что производительность труда сильно увеличилась. Ну да, стало немного удобнее, но не более того.
Ну, если тебе дженерики не увеличили производительность труда, то действительно, интересоваться макросами смысла нет.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

V>Профессиональные сообщества придумывают новые слова, а не новый синтаксис.

Вам не нравится именно новый синтаксис?
Но ведь ваш EDSL для позднего связывания как раз вводит новый синтаксис вызова методов, а макрос late оставляет синтаксис вызова методов неизменным.

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

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

M>>Законы эволюции на кривой кобыле не объедешь. Они объективны.

IT>Законы эволюции были объеханы примерно 30-50 тыщ лет назад на кобыле, называемой речь. Обмен информацией по сравнению с генами ускорился на многие порядки, в результате чего наш вид очень быстро стал доминировать на планете.

Хм... Начало доминирования вида, имнип, как бы раньше прихода второй сигнальной констатируют. Нет?

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

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

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

Другой уровень, знаете ли

---
С уважением, Сиваков Константин.

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можешь привести пример таких задач? Я имею ввиду, чтобы на макросах задача решалась хорошо, а без — сильно хуже. Я уже просил Sinclair'a, он привел в качестве примера динамический доступ к свойствам.

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

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

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

Зато на обычном коде хорошо работают автоматические средства рефакторинга. В отличии от ручных DSL'eй, о которых тулзы ничего не знают.

VD>При этом других средств попросту нет.

Есть — голова на плечах и руки, растущие откуда надо. Это универсальное средство

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

V>Можешь привести пример таких задач? Я имею ввиду, чтобы на макросах задача решалась хорошо, а без — сильно хуже. Я уже просил Sinclair'a, он привел в качестве примера динамический доступ к свойствам.

Толку тебе приводить пример из собственного опыта, если ты не представляешь всей сложности проблемы, решённой макросом.
Любой достаточно сложный проект можно привести в пример. Ты со сложными проектами работал? С какими, приведи пример, и получишь понятный тебе ответ.

V>Зато на обычном коде хорошо работают автоматические средства рефакторинга. В отличии от ручных DSL'eй, о которых тулзы ничего не знают.

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

class Foo {
  Foo(int i) {
    super(i);
  }
}

тебе надо заменить i на некоторый код, который требует временной переменной. А ты эту временную
переменную никуда вписать не сможешь, потому как super() вызов конструктора должен быть _первым_,
никакие декларации переменных и вообще ничего до него быть не может.
Никакой рефакторинг тебе не поможет. И кодо-генерация исходников не поможет — нельзя написать
валидный код. А в языке программирования манипулирующим непосредственно с AST деревом — никаких
проблем.

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

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

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

Читать надо внимательнее. Все это относится к "эти "программисты" не знают ни сишарп, ни тем более немерле.
".

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

G>>Ну хорошо, давай поговорим. Опустим то, что ты мне писал об отличиях причин отследствий (я, как человек с высшим математическим образованием, в курсе этой тонкой разницы), и остановимся для начала на том, в чем ты делаешь ошибку с самого начала. Ты не прав в том, что она базируется на последствиях. Хайп — является не только следствием, но и причиной, это необходимый и важный элемент процесса внедрения инноваций. Допустим, я придумал крутую штуку. Если я о ней не пишу, и она не вызывает бурного обсуждения в публикациях, как ты (а главное — широкая общественность, и инвесторы) о ней узнают? С другой стороны — если я пишу, а хайпа нет — это означает ровно одно. Людям это не интересно, и это не затрагивает никаких значимых потребностей.

M>Так я же сразу сказал — hype это элемент социодинамики вокруг технологии. Конечно, какая-то социодинамика вокруг технологии всегда будет, и её можно померять, тем-же количеством публикаций и пр. Но она вторична, это величина измеряемая, а не причинная.

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

Представь себе некий процесс. В нем есть две составляющие, два разных аспекта ОДНОГО процесса, которые влияют друг на друга в обе стороны в равной степени. Замерив одну из них, ты с хорошей точностью оценишь и другую. Пример из психологии — любая испытываемая эмоция приводит к напряжению определенного паттерна мыжц человеческого тела. Значит ли это, что напряжение мыжц следствие? Нет. Потому, что исследования Лоуэна в свое время показали, что имеет место и 100% обратный эффект — напряжение определенного паттерна мыжц вызывает заданную эмоцию. Ну, что причина, а что следствие? А они не связаны этим отношением. Напряжение мыжц и эмоциональные переживания — два аспекта одного и того же ЕДИНОГО процесса.

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

M>Ты хочешь вложить деньги в новую технологию и получить прибыль. На каком этапе ты это должен делать? Ясно, что не на вершине hype-а. В это время все вкладывают деньги, и через некоторое время теряют их. Банальный эффект толпы — все ломанулись, и попередавили друг друга.

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

То на каком этапе буду инвестировать я — это зависит от того, кто "я". Бизнес-ангел, венчурный капиталист, рядовой обыватель, крупный инвестиционный банк, инвестиционный фонд, обычный трейдер, или частная компания, которая выдает гранты на перспективные для себя исследования. А также от того, как именно я управляю своим портфелем инвестиций — я например могу 20% своих инвестиций вложить в рискованные предприятия, а остальные 80 — в "голубые фишки". Даже в таком банальном случае, как если "я" открыл стартап — у меня вполне может быть запланирована в качестве exit strategy продажа моего стартапа с потрохами крупной компании. Так делают очень многие.

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

M>Простой пример с dynamic языками (Perl, Python, PHP, Ruby). Мы имели кучу хайпа в недавнее время (по видимости, они как раз прошли первый пик). Что с ними будет дальше? Как высоко они пойдут в подъём после прохождения минимума, и пойдут ли вообще, и если пойдут — то в каком направлении будет развиваться технология (от этого зависит — во что именно вкладывать средства)? Почему они выстрелили именно сейчас, а не раньше или позже — ведь они давно существуют!

Хайп-цикл никак не показывает тебе аспекта конкурентной борьбы, он отражает "жизненный цикл". Это во-первых. Что попало на этот график наносить нельзя, это второе. И третье. На кривую хайп-цикла наносят РЕЗУЛЬТАТ анализа, который (анализ) достаточно глубок и разносторонен. Точки на данной кривой — это не входные данные для анализа, это его результат.

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

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

Питон с Руби и PHP, кстати, которые ты помянул, давно уже в мэйнстриме, и свою нишу заняли. Это зрелые технологии, как и Java. А "динамические языки" просто нельзя наносить как точку на хайп, это не является сомостоятельной технологией, это собирательный термин.

G>>Сама кривая хайпа имеет исключительно иллюстративные цели, не являясь мега-методикой, из которой аналитики компании Гартнер делают свои выводы, и серебряной пулей. Она в наглядной форме постоянно напоминает об этой закономерности.

M>Хорошо, в качестве иллюстративной методики у меня к ней претензий нет.
M>Но почему ты тогда советуешь Владу ориентироваться на эту кривую, которая просто иллюстрирует, а не объясняет (в том числе, и "почему развитие идёт именно так")?

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

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

G>>>Питон с Руби и PHP, кстати, которые ты помянул, давно уже в мэйнстриме, и свою нишу заняли. Это зрелые технологии, как и Java. А "динамические языки" просто нельзя наносить как точку на хайп, это не является сомостоятельной технологией, это собирательный термин.

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

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

M>Он точно из ямы выберется?
Кто знает. Дал поиск — в интернете полно обеспокоенных постов, на тему, что "хайп Руби кончился, или мне показалось"?

Волноваться не надо, "яма" всегда сопровождает все технологии при начале более-менее массового внедрения. Немерле, например, такая яма может только снится. "Яма" — это уже хороший признак, это начало массового опробирования индустрией. "Яма" — это "думали, что все круто, а оказалось — и здесь есть свои грабли. Вот ведь блин, фигня какая!". Народ испытывает разочарование. После этого, слабые и сильные стороны технологии будут изучены, и она займет свою нишу. Или — не займет, и ее "обгонит" по тому же циклу (или вытеснит соседняя) более приспособленная к условиям обитания технология.

Кто знает, что будет? Кто знает, как отреагируют на обратную связь индустрии разработчики Руби? Прогноз — это всего лишь прогноз.

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

G>17 самых распространенных ошибок стартапщиков от профессионального успешного стартапщика.

Спасибо, было очень интересно почитать (а ссылочка на первоисточник есть?).

Только вот создается впечатление, что эти советы не на 100% полезны в случае развития какой-то новой технологии. Скорее это советы для тех, у кого есть идея продукта и им требуется пара-тройка лет и N денежек для вывода продукта на рынок. Вот скажем, есть язык Pascal, который сам по себе не продукт. Тогда как компилятор Turbo Pascal -- тот самый продукт, который и стал стартовой точкой для успешного стартапа. Все 17 упомянутых советов очень хорошо относятся именно к Turbo Pascal, но вряд ли бы они пригодились при создании самого языка Pascal.

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

C>в данном случае показательным, это поведение религиозного фанатика, пусть и известного.

Нас интересует не поведение Фишера, а поведение властей США.

... << RSDN@Home 1.2.0 alpha 4 rev. 1096>>

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

IT>>Auto-property как раз, ИМХО, единственная фича, которая linq'у по-боку

AVK>Не единственная. partial methods тож побоку.

Это сделано по большей части не для программистов, а для генераторов.

Неясность изложения обычно происходит от путаницы в мыслях.

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

M>Законы эволюции на кривой кобыле не объедешь. Они объективны.
M>Вот разберись с этими законами, и не надо будет плакаться, ты будешь знать почему так происходит. И иногда даже сможешь придумать как эти законы использовать с пользой для себя.

То есть эволюцию двигают в перед корпорации вроде MS?

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

M>Законы эволюции на кривой кобыле не объедешь. Они объективны.
M>Вот разберись с этими законами, и не надо будет плакаться, ты будешь знать почему так происходит. И иногда даже сможешь придумать как эти законы использовать с пользой для себя.

И много ты их "наиспользовал" для себя? "Пациент (SymADE) скорее жив чем мёртв.... Нееет, пациент скорее мёртв чем жив".

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

VD>То есть эволюцию двигают в перед корпорации вроде MS?

Это был стёб? Очччень хорошо, когда они хотя-бы не стоят у него на пути

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

M>Нет. В эволюционной борьбе экосистема практически всегда сильнее чем один новый вид/технология...
M>Так как нас интересуют компиляторы и языки программирования, то в применении к ним — для нового языка программирования
M>нужна такая ниша, где старые технологии (языки) не справляются. Тогда он будет развиваться. Тогда вокруг него
M>сформируется экосистема (в том числе и люди, знающие этот язык), которая и сможет бороться со старыми языками.
M>Если вы для nemerle не найдёте такой маргинальной ниши — проект засохнет. Найдёте — будет жить и развиваться,
M>как бы его не давили.

Вообще-то я говорил не о языке, а о добавлении новых фич в существующие языки. Скажм С++ немогут доработать вот уже 10 лет. C# меняется раз в 3 года по чайной ложке.

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

Извини, ты статью-то читал?

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

M>В общем, тут можно долго рассказывать, и ещё больше можно размышлять самому. Лично я для SymADE уже выстроил беспроигрышную стратегию.
M>Он будет развиваться в своей маргинальной нише, будет независимо ни от чего — потому как в этой нише у него нет конкурентов.
M>А когда вокруг него сформируется экосистема, когда он станет достаточно зрелым — вот тут он в мэйнстрим и попадёт.
M>И не важно займёт это 10 лет или 15, это произойдёт неприменно, потому как его будут толкать неодолимые силы.
M>Законы природы нельзя отменить, но можно или безуспешно пытаться пробить их лбом, или использовать в своих целях.
M>Но для начала их надо знать

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

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

Что ты понимаешь под словом "маргинальный"?

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

E>>Зачем вообще эта статья была написана?

VD>Выражение мнения.

Ага. Осталось понять, какое именно мнение ты пытался выразить:
1. Что Nemerle -- это рулез.
2. Непонимание того, почему MS внедряет в свои разработки передовые подходы только спустя какое-то время.
3. Что-то еще.

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

VD>Что ты понимаешь под словом "маргинальный"?

Я же писал — "пограничный". Или можно сказать — "на обочине".
Это слово в русском — калька с английского margine.

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

M>Не вижу, почему "иначе". Именно так, как я и написал.
M>У MS уже есть своя экосистема. Называется MS Windows.

Тем более. В этом случае им даже проще ввести в эту экосистему еще и парадигму метапрограммирования. Будут несколько подходов существовать паралельно — как существуют в c# функциональные радости.

M>Другие компании, пусть даже столь-же крупные, не всегда имеют свою экосистему. Ну, IBM имеет экосистему "для большого бизнеса".
M>А такие как Sun, HP — нет. Что-то мелкое есть у Apple, Sony.
M>Понимаешь, вся хохма в том, что далеко не всегда армия pr-щиков и баснословные рекламные компании могут привести к
M>созданию экосистемы.

Это не хохма, это жизнь такая. Но это не значит что не нужно и пытаться создавать что то новое.

M>Для неё должа существовать объективная ниша. Вот Sun пытался продвинуть Java — её изначально
M>создавали для embedded девайсов. А выстрелила она в web-е, как запускался applet-ов. Правда, оказалась слишком
M>неудобной — пока не было конкурентов, апплеты писали. А теперь их полностью вытеснили jscript и flash.
M>Яве сильно повезло — пока она сидела в своей нише для web-апплетиков, она как технология успела сформироваться.
M>И когда её вытесняли, она была достаточно развита, чтоб побороться за другие места. И заняла две странных
M>ниши — web-allocation сервер (для которых её и не предназначали) и мобилки (они как раз стали достаточно
M>мощными, чтоб вместить яву). Это как пример того, что развитие происходит по своим законам, и в них деньги
M>решают далеко не всё. Деньги могут помочь, но не более. Если физически ниша занята другой экосистемой, или
M>приходит лучшая сформировавшаяся экосистема — никакие деньги не помогут.

Я могу опровергнуть вывод даже без контрпримера, поскольку он (вывод) не согласуется с логикой. — Ты привел один _частный_ пример и сделал из него _общий_ вывод.

p.s. Я один не понимаю эту кашу из ниш и экосистем? Где можно ознакомиться с общепринятой классификацией? Вот ты пишешь — "ниша занята экосистемой", и в то же время говоришь об экосистемах компаний. Какую нишу занимает экосистема MS Windows? нишу настольных ОС? или может быть нишу серверных или встраиваемых os? А может наоборот — ос windows содержит в себе нишы, например нишу браузеров или нишу средств разработки? А какой экосистемой сейчас занята ниша средств метапрограммирования? Или правильнее будет написать — кто занимает нишу средств метапрограммирования в экосистеме MS Windows?

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

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

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

M>>Законы эволюции на кривой кобыле не объедешь. Они объективны.

IT>Законы эволюции были объеханы примерно 30-50 тыщ лет назад на кобыле, называемой речь. Обмен информацией по сравнению с генами ускорился на многие порядки, в результате чего наш вид очень быстро стал доминировать на планете. Если бы всё развивалось по объективным законам, то мы бы ещё вряд ли доросли до изобретения колеса.
Спорно... Думаю, речь обязана развитию речевого аппарата и мозга, на развитие которых, в свою очередь ушло гораздо больше времени.
Не с

IT>Что касается Немерле, то в нём есть вещи, способные ускорить эволюционные процессы, теже макросы, о которых говорит Влад. Конечно, это ускорение не на порядки, а всего лишь в разы, но надежда есть.
Введение новых механизмов в C# сравнимо с эволюцией речевого аппарата и мозга, а реализация функционала на макросах Nemerle — это развитие речи.

Надо понимать, что в отличие от разработчиков Nemerle изъять функционал будет гораздо сложнее. Т.к. сообщество разработчиков C# в сотни раз больше.
Плюс, следует добавить сюда бюрократическую систему, коей страдают ВСЕ большие организации и внутреннюю политику, т.е. с мнением разных людей считаются по разному.

... << RSDN@Home 1.2.0 alpha rev. 787>>

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

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

Не важно сколько и чего развивалось раньше. Главное, что появился механизм, которому стало плевать на вашу эволюцию. При чём механизм этот у нас перед глазами.

Вообще-то это я к вопросу об аналогиях. Даже такая аналогия, если принять её подходящей, не сработала в жизни. А уж если считать её спорной, то и говорить не о чем.

Неясность изложения обычно происходит от путаницы в мыслях.

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

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

M>>Не вижу, почему "иначе". Именно так, как я и написал.
M>>У MS уже есть своя экосистема. Называется MS Windows.
S>Тем более. В этом случае им даже проще ввести в эту экосистему еще и парадигму метапрограммирования. Будут несколько подходов существовать паралельно — как существуют в c# функциональные радости.

Конечно могут.
Мне в переписке один из участников проекта Intentional Programming сказал, что когда MS стал выбирать
технологию программирования следующего поколения, то были две возможности — IP и .NET, выбрали .NET,
а IP похерили, даже не столько из-за недостатка ресурсов и незаконченности проекта, сколько из-за
нежелания смущать пользователей (программистов). Чтоб было одно генеральное направление, ясное
и понятное.

M>>Другие компании, пусть даже столь-же крупные, не всегда имеют свою экосистему. Ну, IBM имеет экосистему "для большого бизнеса".
M>>А такие как Sun, HP — нет. Что-то мелкое есть у Apple, Sony.
M>>Понимаешь, вся хохма в том, что далеко не всегда армия pr-щиков и баснословные рекламные компании могут привести к
M>>созданию экосистемы.

S>Это не хохма, это жизнь такая. Но это не значит что не нужно и пытаться создавать что то новое.

Здрасьте. А я чем по твоему занимаюсь, со своим SymADE?!

S>Я могу опровергнуть вывод даже без контрпримера, поскольку он (вывод) не согласуется с логикой. — Ты привел один _частный_ пример и сделал из него _общий_ вывод.

Вывод?! Я привёл иллюстративный пример, где ты нашёл какой-то вывод/доказательство???

S>p.s. Я один не понимаю эту кашу из ниш и экосистем? Где можно ознакомиться с общепринятой классификацией? Вот ты пишешь — "ниша занята экосистемой", и в то же время говоришь об экосистемах компаний. Какую нишу занимает экосистема MS Windows? нишу настольных ОС? или может быть нишу серверных или встраиваемых os? А может наоборот — ос windows содержит в себе нишы, например нишу браузеров или нишу средств разработки? А какой экосистемой сейчас занята ниша средств метапрограммирования? Или правильнее будет написать — кто занимает нишу средств метапрограммирования в экосистеме MS Windows?

В данном конктексте под нишей имелась в виду некое пространство, в котором можно существовать.
Скажем, есть различные климатические регионы на Земле — в них живут разные животные и растения, образуют замкнутые экосистемы.
Но и Земля в целом — тоже ниша, тоже пространство для жизни.
И внутри одной экосистемы есть разные ниши — хищники и жертвы, падальщики и т.п.
Что до MS Windows — это экосистема. Она доминирует в области десктопных приложений. Она пытается занять другие ареалы — сервера,
игровые приставки, смартфоны и пр. Да, в ней, как в экосистеме, тоже есть различные пространства для жизни — для броузеров,
для средств разработки, для оффисных приложений и т.п.
Мета-программировние сейчас занято, по моему, в основном всякой всячиной — и генераторами кода, и lisp-ами, и AOP-ами
и другой мелочёвкой.

S>Ну хорошо, напиши плиз какую нишу сейчас занимает или какой экосистемой является платформа .net и c# в частности и каким образом парадигма метапрограммирования может ослабить их позиции? Напомню, что речь идет о _добавлении_ новых фич в существующий язык.

Нишу средств программирования под платформу MS Windows, какую-же ещё. Постепенно вытесняет устаревшие средства
и языки программирования.
Если MS будет противится парадигме мета-программирования, то на десктоп оно прийдёт только сместив windows,
в составе другой операционки. Но врядли MS будет сильно упираться. Когда увидит, что мета-программирование
всё шире используется и реально приносит бабки — сделают свою систему (или купят готовую), и тесно
синтегрируют с виндой.
Вот возьмём SymADE — ему всё равно, с каким языком работать. У него не фиксированный набор семантических
узлов для внутреннего представления программы. И ему всё равно как отображать внутреннее представление — можно и
так, что выглядеть оно будет как текст на c#. Берёт человек SymADE, импортирует свой код на C# — и видит
всё то-же, и может делать всё то-же. Но плюс к тому — он может добавить в этот импортированный код свои
семантические сущности, и они будут для SymADE всё так-же как родные. И если очень захочется — он сможет
экспортировать код обратно в текстовый вид, в код C# (то есть SymADE будет работать кодогенератором).
Как Влад писал — в Nemerle добавили новый макрос, и получили late binding. Только Nemerle
для этого надо иметь свой собственный синтаксис, отличный от C#-повского. А SymADE-у не надо.
Он вообще с текстом и синтаксисом не работает, он рендерит разным образом внутреннее предстваление
кода. Он с таким-же успехом может отображать (или экспортировать) тот-же самый код, ту-же самую
программу в виде Visul Basic-а, а не в виде С#.

В результате, после долгого развития проекта на C#, когда его программисты упрутся в чрезмерную сложность
выросшего проекта, и захотят средств мета-программирования — они без малейших усилий смогут начать
использовать SymADE. А Nemerle не смогут. От такие пироги. От так и будет мета-программирование
вытеснять C#.

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

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

Самец самке:
-- Я нашел новую банановую рощу.
-- Чёё, не понимаю тебя
-- Рощу банановую, говорю, нашел
-- Нифига непонятно
-- Блин, опять ребенка делать надо, а то так и помрем без бананов...

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

M>В результате, после долгого развития проекта на C#, когда его программисты упрутся в чрезмерную сложность
M>выросшего проекта, и захотят средств мета-программирования — они без малейших усилий смогут начать
M>использовать SymADE.
Утопия какая-то

А оно работает? Или хотя бы идеи есть как этого достичь?

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

M>>В результате, после долгого развития проекта на C#, когда его программисты упрутся в чрезмерную сложность
M>>выросшего проекта, и захотят средств мета-программирования — они без малейших усилий смогут начать
M>>использовать SymADE.

A>Утопия какая-то

Преувеличение, не более того

Конечно, усилия нужны будут. Даже при переходе с одной IDE на другую нужны усилия.

A>А оно работает? Или хотя бы идеи есть как этого достичь?

Ну, в виде прототипа — работает. Только у меня один backend — для JVM, и реализована
поддержка только одного языка (который расширение java). Поскольку среда ещё в состоянии
альфы, а работать надо — большая часть кода у меня в текстовом виде. Но новые фичи я
реализую уже без текстового синтаксиса, прямо во внутреннем виде редактирую. Скажем,
те-же "макросы", точнее "цитирование". Ну и всякие вспомогательные вещи. Скажем, язык
отображения (рендеринга) дерева у меня вообще текстового вида никогда не имел.

Для поддержки .NET/C#/VB объём работы я бы оценил в человеко-год. Ну и на доводку SymADE
как платформы до беты — ещё пару человеко-лет. Таких ресурсов у меня нет, поэтому в .NET я
полезу не скоро.

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

M>Берёт человек SymADE, импортирует свой код на C# — и видит всё то-же, и может делать всё то-же. Но плюс к тому — он может добавить в этот импортированный код свои семантические сущности, и они будут для SymADE всё так-же как родные.
M>И если очень захочется — он сможет экспортировать код обратно в текстовый вид, в код C# (то есть SymADE будет работать кодогенератором).
Ага... берем код на немерле.
Импортируем в SymADE.
Экспортируем в C#.
Получаем нечитаемую кашу.

Если взять вместо немерле хаскель то все будет совсем плохо.

Если взять схему то мы вобще не сможет провернуть этот фокус.

А если в один проект в сумаде импортировать код на схеме и на С++ то получим теоритически неработоспособную кашу.

Вот такие вот пирожки с котятами...
Короче Имею Мнение Хрен Оспоришь что если у систему программирования не будет непротиворичивого фундамента то ничего работать не будет.

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

WH>Ага... берем код на немерле.
WH>Импортируем в SymADE.
WH>Экспортируем в C#.
WH>Получаем нечитаемую кашу.

Всё правильно.
Только я приводил пример возможности перехода на SymADE для сложного проекта.
А ты говоришь о невозможности использовать SymADE как транслятор с одного языка на другой.
Так он для этого и не предназначен.
Я сейчас могу экспортировать код своей программы в java — и получаю нечитаемую кашу.
Так я и не экспортирую, а компилирую в .class файлы напрямую. И отлично работает.

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

Как обычно игнорируешь то на что не можешь возразить?

Если взять схему то мы вобще не сможет провернуть этот фокус.

А если в один проект в сумаде импортировать код на схеме и на С++ то получим теоритически неработоспособную кашу.

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

WH>Как обычно игнорируешь то на что не можешь возразить?

Избегаю оверквотинга. Ответ всё тот-же, SymADE — не компилятор с одного языка на другой.

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

IT>>Обмен информацией по сравнению с генами ускорился на многие порядки, в результате чего наш вид очень быстро стал доминировать на планете.
A>Кхе-кхе. Получается весь животный (и растительный) мир общается исключительно на генном уровне и других средств коммуникации у них нет. Ню-ню.

Коммуникации чего? Где банановая роща? Это слишком примитивно. Вот если бы так же легко происходил обмен информацией о том, что кроме бананов есть ещё и огурцы, а огурцы это ещё и ценный мех! Вот тогда другое дело.

Неясность изложения обычно происходит от путаницы в мыслях.

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

IT>>Законы эволюции были объеханы примерно 30-50 тыщ лет назад на кобыле, называемой речь.

M>Ты понимаешь под словом "эволюция" только эволюцию живой природы? Напрасно.

Я понимаю под словом эволюция эволюцию. Ты использовал примеры эволюции живой природы, я привёл тебе ещё один.

Неясность изложения обычно происходит от путаницы в мыслях.

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

M>Избегаю оверквотинга. Ответ всё тот-же, SymADE — не компилятор с одного языка на другой.
Еще раз:

А если в один проект в сумаде импортировать код на схеме и на С++ то получим теоритически неработоспособную кашу.

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

IT>Вот если бы так же легко происходил обмен информацией о том, что кроме бананов есть ещё и огурцы, а огурцы это ещё и ценный мех! Вот тогда другое дело.
Ничего не понял

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

WH>Еще раз:
WH>

А если в один проект в сумаде импортировать код на схеме и на С++ то получим теоритически неработоспособную кашу.

Мы уже это обсуждали — кончилось дело тем, что ты закрыл возможность ответа, и на этом обсуждение закончилось.
Да, у C++ и схемы разные, несовместимые модели стека.

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

IT>>Я понимаю под словом эволюция эволюцию. Ты использовал примеры эволюции живой природы, я привёл тебе ещё один.

M>Пример эволюции живой природы? Какое к ней имеет отношение язык? Эволюции "цивилизации" (человеческой культуры)?
M>Какое она имеет отношение к живой природе?

Не напомнишь автора этой цитаты:

Вот простой пример из эволюции жизни на Земле. Травка (степь) вытеснила леса.

и кокое это имеет отношение к этому примеру имеет данная тема?

Неясность изложения обычно происходит от путаницы в мыслях.

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

M>Мы уже это обсуждали — кончилось дело тем, что ты закрыл возможность ответа, и на этом обсуждение закончилось.
M>Да, у C++ и схемы разные, несовместимые модели стека.
Те ты признаешь что в общем случае невозможно совместно использовать два семантических дерева созданных разными людьми в одной программе?

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

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

IT>>>Я понимаю под словом эволюция эволюцию. Ты использовал примеры эволюции живой природы, я привёл тебе ещё один.

M>>Пример эволюции живой природы? Какое к ней имеет отношение язык? Эволюции "цивилизации" (человеческой культуры)?
M>>Какое она имеет отношение к живой природе?

IT>Не напомнишь автора этой цитаты:

Он спросил, какое отношение язык имеет к эволюции живой природы, т.е. к его примеру.
А ты пытаешься сказать, что аналогию провести нельзя, потому что 2+2 = 4. Так какое отношение этот факт имеет к его примеру? Как он его опровергает?
Вот я тоже выше спросил, чем язык мешает или как он что-то опровргает?

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

VE>Хотелось бы уточнить, а то я мысль не до конца понял.
VE>Всё развивается по объективным законам. Где произошёл "объезд"? Т.е. каким образом речь не вписывается в законы эволюции-то?

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

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

Неясность изложения обычно происходит от путаницы в мыслях.

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

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

IT>Эволюционно передача знаний и опыта происходит с помощью генов. Для того, чтобы позитивные знания, с точки зрения прогрессирования определённого вида, надёжно закрепились в генах нужны десятки/сотни/тысячи поколений.

IT>С помощью речи знания передаются не только от поколения к поколению, но и внутри одного поколения. Соответсвенно развитие вида начинает идти на порядки быстрее и уже отличным от эволиции способам.

Развитие вида продолжает идти так же. Речь, умение обучаться, это всё инструменты, как клыки и быстрые ноги. Да, возможность передачи информации позволило развиться, заполонить планету, но не изменило вид. До сих пор в нас инстинкты 10-тысячелетней давности, о каком развитии вида идёт речь?

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

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

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

Даже если говорить о "сбоях" (хотя человек им не является, просто для продолжения мысли), то в любом случае есть два варианта:
— это неизученная закономерность
— это стечение обстоятельств, позволившее этому произойти
Из этого можно сделать простые выводы:
— Занять доминирующее положение можно не только изначально описанным способом, но и еще каким-то (неизученным, кажущимся нам сбоем), либо ждать чуда.
В любом случае, я предпочел бы иметь конкретную вероятность (ещё лучше — гарантии), а не надеяться на чудо.
Хотя некоторые, конечно, лечатся, категорически не пользуясь лекарствами, а принимая что-то своё, утверждая, что наука этого не изучила, поэтому ничего об этом не знает.
В общем-то, если других вариантов нет, то все методы хороши.

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

VE>Развитие вида продолжает идти так же. Речь, умение обучаться, это всё инструменты, как клыки и быстрые ноги. Да, возможность передачи информации позволило развиться, заполонить планету, но не изменило вид. До сих пор в нас инстинкты 10-тысячелетней давности, о каком развитии вида идёт речь?

О каком развитии? Ну хотя бы в отличии от 10-ти тысячелетней давности конкретно мы с тобой приобрели способность общаться, находясь друг от друга в десятках тысяч километров.

Неясность изложения обычно происходит от путаницы в мыслях.

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

IT>О каком развитии? Ну хотя бы в отличии от 10-ти тысячелетней давности конкретно мы с тобой приобрели способность общаться, находясь друг от друга в десятках тысяч километров.

Но это же не развитие вида. Мы обладали всеми необходимым способностями, чтобы заниматься этим, и 10к лет назад. Другое дело, что не было технологий, но научиться стучать по клавиатуре и читать с монитора мог и тот человек. Наш вид обладает способностью изменять окружающую среду, но на это, разумеется, нужно время. Но даже через еще 10000 лет мы не сможем ходить по Луне без каких-либо приспособлений. Мужчины так и будут стремиться занять доминирующее положение, завоевать больше самок и размножиться. Женщины также будут искать себе лучшего самца, чтобы оставить потомство. То, что это сопровождается изменением окружающей среды, на вид не влияет.
Я вряд ли смогу найти очень хороший пример (так как не столько знаю животных), но хотя бы такой пример: 2 года назад муравьи не могли принести себе в муравейник дохлую ящерицу, а теперь могут. Это разве значит, что их вид изменился? Очевидно, нет. Их численность стала достаточной, муравейник стал необходимых размеров.
Сложность нахождениея примера в том, что я лично сходу не припомню каких-либо еще животных, меняющих окружающую среду под себя, а не приспосабливающихся к новой в результаты эволюции.
Человек умеет адаптироваться, это позволило ему более комфортно жить там, где другие не могли этого сделать. Развившись до такой степени, что теперь он мог уже потеснить и хозяев других экосистем, он занял и их, а непригодные стал подстраивать под себя.
Кстати, попугай КЕА живёт в достаточно суровых условиях и обладает неплохими умственными способностями и способностями действовть сообща. Он ушёл в другую нишу, где развитый мозг ему просто необходим (это проще, чем вернуться в комфортную нишу, которая занята, там ему верная гибель). Глядишь, научится общаться, других птиц потеснит да шалаши строить начнёт.

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

IT>>О каком развитии? Ну хотя бы в отличии от 10-ти тысячелетней давности конкретно мы с тобой приобрели способность общаться, находясь друг от друга в десятках тысяч километров.

VE>Но это же не развитие вида. Мы обладали всеми необходимым способностями, чтобы заниматься этим, и 10к лет назад. Другое дело, что не было технологий, но научиться стучать по клавиатуре и читать с монитора мог и тот человек. Наш вид обладает способностью изменять окружающую среду, но на это, разумеется, нужно время. Но даже через еще 10000 лет мы не сможем ходить по Луне без каких-либо приспособлений.

Не, ты не понимаешь. Какая разница как ходить по луне, в скафандре или без? Муравьи ни через 10k, ни через 10kkk лет не смогут ходить по луне хоть с приспособлениями, хоть без них. А вот муравейники (города) мы уже научлись строить не хуже муравьёв. Да и модификация свойств непосредственно самого человека — это дело времени, технологии дорастут и до этого. Главное, что в основу всего этого положен не эволюционный путь развития, а совершенно другой. Благодаря речи человек смог вырваться из оков эволюции и сразу же стал доминировать: съел всех мамонтов, сжёг Австралию, приручил животных, построил города, создал машины, ядерное оружие и интернет, полетел в космос. Без развития речи мы смогли воспользоваться всем этим ещё очень не скоро.

Неясность изложения обычно происходит от путаницы в мыслях.

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

IT>О каком развитии? Ну хотя бы в отличии от 10-ти тысячелетней давности конкретно мы с тобой приобрели способность общаться, находясь друг от друга в десятках тысяч километров.

Вы, очевидно, путаете вид (совокупность генов) и представителей вида; как многие путают класс и объект. Пока вы не измените класс, каждый новый созданный объект будет именно этого класса. Да, в процессе жизни ему можно поменять свойства, но это будет объект именно этого класса. Да, он может создать много новых файлов, полазить в реестре, изменить конфигурацию компьютера так, что некоторые его свойства начнут проявляться лучше, но это будет объект всё того же класса.

Так вот, проводя аналогию, вид — это технология (совокупность тулз, компиляторов, документации). Представители вида — это непосредственное использование технологии.
Чтобы вид развивался, необходимо
1) его представители должны успешно жить и размножаться
2) вид должен развиваться
3) после того, как вид (как совокупнсть генов) достигнет определенной точки, его представители смогут распространиться за пределы своей экосистемы
Для второго, очевидно, необходимо первое.
Чтобы развивалась технология, необходимо
1) она должна использоваться для понимания ее недостатков и достоинств
2) технология должна изменяться
3) после того, как она станет достаточно развитой, ее использование выйдет за пределы изначальной лаборатории и потеснит "использования других технологий" (саму другую технологию она, очевидно, не уничтожит)

Так вот суть изначальной аналогии в том, что в занятой экосистеме представители вида жить не смогут, потому что за много лет их вид приспособился к конкретной системе и любое изменение приводит к ухудшению продуктивности. Т.е. вид достиг предела, он совершенен в совокупности с данной средой (но не абсолютно, это локальный максимум). Но! Изменение может принести выгоду в другой среде, незанятой другим видом, который был бы совершенен в совокупности с ней. Таким образом представители вида начинают жить в новой среде и начинают изменяться в сторону усовершенствования. Тут среда также очень важна, так как в немалой доле именно ей будет определяться, в какую сторону будет совершенствоваться вид.
Далее вид может измениться так, что он станет приспособлнен к той среде, но вернуться обратно уже не сможет.
А может оказаться так, что он будет лучше приспособлен и к другим средам. Как? Я писал выше, что "совершенство" означало лишь локальный максимум. Выйдя в другую среду, этот вид достиг в ней (другой среде) своего локального максимума, но могло оказаться так, что в предыдущей среде его положение оказалось выше. Резко этот скачок произойти не мог, потому и необходим уход в другую среду.
Понятно, что выйдя в другие среды, вид будет хотя и лучше "коренного" вида, но не будет находиться в максимуме новой среды, и продолжит эволюцию, возможно, с новым отделением вида.

Кратко. Продуктивность есть функция среды от вида. В среде живет тот вид, продуктивность которого выше остальных. Эволюцию непрерывно изменяет вид так, что он достигает максимума, очевидно, локального. Чтобы покинуть локальный максимум и выйти далее, надо найти другую среду, где продуктивность вида будет максимальна. Там он достигнет нового локального максимума (в той среде, т.е. это уже другая функция). Вернувшись обратно, может оказаться так, что в изначальной среде его продуктивность будет выше, и он потеснит живущий там вид, и продолжит эволюцию до достижения нового локального максимума.

Пример:
f(x) = sin(x * pi/2) * x // среда 1
g(x) = — (x-4,8)^2 // среда 2

Начиная с точки 0, в среде f достигнется максимум в точке (1+,1+)
Выйдя в среду g, вид начнет совершенствоваться и дойдет до дочки (4.8,0)
Вернувшись обратно, случайно окажется, что в среде f теперь его продуктивность будет выше, чем 1. Он продолжит совершенствоваться и достигнет максимума в точке (5+,5+), хотя и это не предел.

Иллюстрация:

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

Видимо, наступило некоторое взаимонедопонимание.
Уточню, человек вытеснил других животных вполне себе по законам эволюции.
То, что сейчас развитие идёт гораздо быстрее, то это вполне естесственное распространение человека. Если б также распространились слоны, тоже нагадили бы везде и леса вытоптали, к примеру. Сам же человек не меняется (т.е. обычными темпами). Склонировать древнего египтянаниа, и он одолеет велосипед и автомобиль без проблем.

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

Т.е. у нас разговор-то идёт в контексте вытеснения одних другими, а я вот не пойму, кто кого вытесняет последние 100 лет не по законам эволюции? Человек это уже сделал вполне законно.

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

VE>А вот это и будет целенаправленное изменение вида, которое пока подвластно лишь эволюции.
Про генномодифицированные продукты напомнить?
Еще можно посмотреть Ghost in the shell. Оно конечно фантастика но кто знает куда лет через 100 технологии заведут.

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

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

VE>>А вот это и будет целенаправленное изменение вида, которое пока подвластно лишь эволюции.
WH>Про генномодифицированные продукты напомнить?
WH>Еще можно посмотреть Ghost in the shell. Оно конечно фантастика но кто знает куда лет через 100 технологии заведут.
На этом, собственно, аналогия кончается.
Видообразование не аналогично. Технологию можно создать с нуля, вид же просто обязан отделяться, эволюционирую непрерывно.
Формально один человек может в подвале ваять новый ЯП, а потом выйти в свет с супер ИДЕ, с кучей документации на всех языках, с миллионами тулз и библиотек для взаимодействия с другими ЯПами и технологиями. Но один он не сможет, так как миллионы людей, заинтересованных в других технологиях всегда будут впереди него уж по наличию доков и тулз однозначно. Поэтому выходить надо раньше, когда технология (вид) еще не стала лучше тех, что уже имеются. А выйти можно только в другую среду, а не в ту, что занята, так как в ней ему ничего не светит.

Твой пример с продуктами всего лишь позволяет сделать резкий скачок, переходя локальный максимум быстрее. Этот скачок в технологиях доступен изначально.
Если мы научимся создавать продукт с нуля (не меняя текущий), то один гений-генетик, создавая новую версию помидора либо будет безнадежно отставать от остальных, либо выпустит бета-версию своего помидора, но она не заменит все помидоры до тех пор, пока не станет лучше их, а пока можно воспользоваться например тем, что помидор может жить при -40, хотя и зеленый и не такой вкусный. А вот потом, когда сделает его красным и вкусным, можно будет и обычные теплолюбивые потеснить.
Этот преждевременный выход нужен лишь для более быстрого доведения задуманного до конца, иначе можно просто опоздать.

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

Хотя почему же.
Формально и две обезьяны могут отделиться ото всех, живя в пещере и через 100млн лет выйти людьми. Но будет поздно.
Эволюция среди 100000 обезьян будет идти явно быстрее, чем среди 2.
Так же и тут.
Можно одному ваять что-то, но эволюция будет идти слишком медленно.
Для того, чтобы повысить популяцию, надо выйти в свет. Все начнут использовать технологию (как я приводил аналогию, использование — это и есть представитель вида), популяция вырастет, эволюцию ускорится и вуаля.
Но выйти-то куда?
Вот тут и проводится аналогия, что выйти в занятую нишу не получится, потому что новая технология пока недостаточно совершенна, но занять нишу "у меня дома", то это будет слишком медленно.

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

VE>Видимо, наступило некоторое взаимонедопонимание.
VE>Уточню, человек вытеснил других животных вполне себе по законам эволюции.

Это не так. В результате эволюции человек получил свойство, которое позволило ему развиваться в обход эволюции, что в свою очередь позволили человеку доминировать. Что же касается эволюционных изменений в человеке за это время. За последние 10 тысяч лет это было приобритение голубых глаз и заметное увеличение роста в последние 100-200 лет. Хотя последнее связано скорее не с эволюцией, а с улучшенным питанием. Не думаю, что наши предки валили мамонтов одним взглядом голубых глаз приобретённых в результате эволюции. Развитие шло совсем иным путём.

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

Неясность изложения обычно происходит от путаницы в мыслях.

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

Ваш пример, что человек может сам изменять гены, обскакав эволюцию.
Пожалуйста:
Человеческий вид достиг такого уровня, что может изменять вид целенаправленно, не пользуясь ресурсами эволюции, а пользуясь своими умственными ресурсами.

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

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

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

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

VE>>Видимо, наступило некоторое взаимонедопонимание.
VE>>Уточню, человек вытеснил других животных вполне себе по законам эволюции.

IT>Это не так. В результате эволюции человек получил свойство, которое позволило ему развиваться в обход эволюции, что в свою очередь позволили человеку доминировать.
Он жил в своей нише. В незанятой. Занятой только им, где он был лучшим. В этой нише он не конкурировал с другими. А вот если бы он в воду нырнул с рыбами плавать, ничего бы он не получил, занято уже.

IT>Что же касается эволюционных изменений в человеке за это время. За последние 10 тысяч лет это было приобритение голубых глаз и заметное увеличение роста в последние 100-200 лет. Хотя последнее связано скорее не с эволюцией, а с улучшенным питанием. Не думаю, что наши предки валили мамонтов одним взглядом голубых глаз приобретённых в результате эволюции. Развитие шло совсем иным путём.
Насчет голубых глаз не скажу, конечно, но признак, который не мешает и не помогает, вполне может появиться, развиваться только не будет до предела.

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

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

SI_>Мне кажется, единственный способ прекратить это безобразие — устроить Влада в Microsoft

Ага, nikov'а вон уже устроили в Майкрософт. Посмотрим, как это скажется на качестве компиляторов.

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

IT>Эволюционно передача знаний и опыта происходит с помощью генов. Для того, чтобы позитивные знания, с точки зрения прогрессирования определённого вида, надёжно закрепились в генах нужны десятки/сотни/тысячи поколений.

У высших животных, очень большая часть знаний уже передается через обучение.

IT>С помощью речи знания передаются не только от поколения к поколению, но и внутри одного поколения. Соответсвенно развитие вида начинает идти на порядки быстрее и уже отличным от эволиции способам.

Угу только речь возникла не на пустом месте. И речь никак ни влияет на биологическое развитие вида. Кстати высшие приматы нормально обучаются речи (язык жестов для глухонемых) и уже самостоятельно обучают ей своих детенышей.

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

IT>Я понимаю под словом эволюция эволюцию. Ты использовал примеры эволюции живой природы, я привёл тебе ещё один.

Нормально вписывается в туже тризовскую эволюцию систем.

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

IT>Это не так. В результате эволюции человек получил свойство, которое позволило ему развиваться в обход эволюции, что в свою очередь позволили человеку доминировать. Что же касается эволюционных изменений в человеке за это время. За последние 10 тысяч лет это было приобритение голубых глаз и заметное увеличение роста в последние 100-200 лет. Хотя последнее связано скорее не с эволюцией, а с улучшенным питанием. Не думаю, что наши предки валили мамонтов одним взглядом голубых глаз приобретённых в результате эволюции. Развитие шло совсем иным путём.

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

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

Пока не сильно деградирует, скорее наоборот http://txt.newsru.com/world/12dec2007/evolv.html

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

IT>Не напомнишь автора этой цитаты:

IT>

IT>Вот простой пример из эволюции жизни на Земле. Травка (степь) вытеснила леса.

IT>и кокое это имеет отношение к этому примеру имеет данная тема?

Такой, что точно так-же динамические скриптовые языки (вроде PHP) заняли нишу в которой раньше доминировали ява, С и пр.
Принцип тот-же.

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

M>>Да, у C++ и схемы разные, несовместимые модели стека.
WH>Те ты признаешь что в общем случае невозможно совместно использовать два семантических дерева созданных разными людьми в одной программе?

Это зависит от смысла слов, вкладываемых в "общий случай" и "использовать".
При определённых ограничениях вполне возможно использование С++-ных семантических понятий и Shema-ных семантических понятий в одной программе,
и даже в одном куске кода. Если эти ограничения не соблюдать — то невозможно гарантировать правильность работы программы.
Впрочем, её невозможно гарантировать и при использовании одного набора семантических понятий — неправильную программу
можно написать на любом языке. При использовании одного набора семантических понятий — набор ограничений намного меньше,
это правда.

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

M>Впрочем, её невозможно гарантировать и при использовании одного набора семантических понятий — неправильную программу можно написать на любом языке. При использовании одного набора семантических понятий — набор ограничений намного меньше, это правда.
Правильность программы понятие субъективное.
Я говорю о другом.
Имея четко определенный фундамент всегда можно однозначно определить что делает код.
В твоей системе это сделать невозможно.
Просто по тому что один фанатик С++ напишет работу с XML. Другой фанатик схемы напишет работу с HTTP.
А прикладной программист не сможет использовать эти две подсистемы в своей программе.
Просто по тому что скомпилировать их в рамках одного дерева невозможно.

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

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

Только для достаточно простой системы. Начиная с определённого уровня сложности — это становится делать
всё дороже и дороже, аж пока нам не хватит всех ресурсов вселенной. Можно держать систему простой увеличивая
количество уровней абстракции, но такая система будет всё менее и менее эффективна.
Если взять для примера биологическую эволюцию, то она во всех местах пошла по пути — "пусть мы
приблизительно, а не точно, можем управлять своим состоянием — но зато это будет намного экономнее
и эффективнее".
Конечно, в живой природе тоже организмы имеют несколько уровней абстракции. Скажем, управление
внутренним состоянием клетками достаточно отделено от управления состоянием организма. Но в пределах
одного уровня абстракции — мы можем очень и очень приблизительно определить текущее состояние и
результаты управляющего или внешнего воздействия.

WH>В твоей системе это сделать невозможно.

Почему? У меня вообще нет системы. У меня среда разработки программ. IDE. Что ты в неё вложишь —
то ты и получишь. Вложишь противоречивый набор семантических понятий — так и будет.

WH>Просто по тому что один фанатик С++ напишет работу с XML. Другой фанатик схемы напишет работу с HTTP.
WH>А прикладной программист не сможет использовать эти две подсистемы в своей программе.

А сейчас может?

WH>Просто по тому что скомпилировать их в рамках одного дерева невозможно.

А работу SQL и C++ можно в рамках одного дерева скомпилировать? Компилируют же.
Неужели у них настолько одинаковые семантические модели? Нет, просто между ними
можно проложить (сгенерировать) gateway — C-шный код пошлёт SQL запрос серверу,
а тот будет вызывать C-шные embedded процедуры.

Но я ещё раз хочу напомнить — SymADE это не компилятор из одной семантической модели
в другую. Он не предназначен соединять вместе SQL и C++ и Scheme. Он предназначен
оперировать семантическими понятиями. Вместо SQL лучше использовать нечто вроде LINQ,
которы позволит всё то-же, но может быть скомпилирован в разные представления, и использовать
разные модели данных, не только реляционные базы данных. SymADE не предполагает,
что разнородные языки будут сведены вместе, он предполагает, что программист определит
новые семантические понятия, в терминах которых и напишет программу. А скомпилировать
её можно будет в разный backend — в С++, в Scheme и т.п. Он больше ориентирован
на декларативное программирование, при этом программист может определять новые
декларируемые семантические понятия.

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

WH>Для абсолютно любой.
WH>Если модель системы не противоричива то мы всегда можем однозначно интерпритировать код системы.
WH>Размер не имеет значения.

http://ru.wikipedia.org/wiki/Теоремы_Гёделя_о_неполноте

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

Эволюция не имеет отношения к вопросу "Почему прогресс идёт так медленно"?!

WH>А твой движек который оперирует семантическими понятиями это что?

Шаблон. Заготовка. Можно не использовать, написав свою систему типов, свой резолвер имён и пр.

WH>>>Просто по тому что один фанатик С++ напишет работу с XML. Другой фанатик схемы напишет работу с HTTP.
WH>>>А прикладной программист не сможет использовать эти две подсистемы в своей программе.
M>>А сейчас может?
WH>Если все трое пушут на жабе то да.
WH>Ибо плюсовику придется забыть про деструкторы, а любителю схемы про континюэйшены.

Зачем забывать про деструкторы? Они отлично реализуются на системе поддерживающей stack unwinding.
Это вопрос backend-а, а не онтологии (языка).
И продолжения можно использовать, при определённых условиях — отказаться от аппаратного стека (хранить в хипе),
отказаться от предположения о том, что unwinding стека будет происходить всего один раз и т.п.

WH>При всех недостатках жабы она имеет убийственное преимущество перед твоей системой: непротиворичивая модель

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

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

FR>Не в обход эволюции, просто это свойство позволило начать эволюционировать социальной надсистеме. И сейчас бурно развивается человек ни как биологический вид, а как человеческая цивилизация. Почитай того же Турчина, Моисеева или ТРИЗ.

Это уже совсем другая эволюция.

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

FR>Пока не сильно деградирует, скорее наоборот http://txt.newsru.com/world/12dec2007/evolv.html

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

Неясность изложения обычно происходит от путаницы в мыслях.

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

FR>У высших животных, очень большая часть знаний уже передается через обучение.

Видимо этого пока явно не достаточно.

FR>Угу только речь возникла не на пустом месте. И речь никак ни влияет на биологическое развитие вида.

С этим никто и не спорит. Пока действительно не влияет.

FR>Кстати высшие приматы нормально обучаются речи (язык жестов для глухонемых) и уже самостоятельно обучают ей своих детенышей.

А детёныши своих детёнышей обучают?

Неясность изложения обычно происходит от путаницы в мыслях.

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

IT>>Эволюционно передача знаний и опыта происходит с помощью генов. Для того, чтобы позитивные знания, с точки зрения прогрессирования определённого вида, надёжно закрепились в генах нужны десятки/сотни/тысячи поколений.

M>Вот я и говорю — ты под словом "эволюция" понимаешь только биологическую эволюцию.
M>Я под словом "эволюция" понимаю процесс развития вообще.

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

IT>>С помощью речи знания передаются не только от поколения к поколению, но и внутри одного поколения. Соответсвенно развитие вида начинает идти на порядки быстрее и уже отличным от эволиции способам.

M>Это тоже эволюция, это тоже процесс развития.

M>Прочитай хоть определение терминов, прежде чем спорить о предмете
M>http://ru.wikipedia.org/wiki/Эволюция

Ну понятно. Ладно, попробуем ещё раз. Сосредоточься и следи за мыслью. Начнём с биологии. Итак, в процессе биологической эволюции человек приобрёл свойство, которое позволило ему развиваться вне рамок биологической революции. Надеюсь с этим ты не будешь спорить. Это показывает, что развитие определённого свойства в процессе эволюции, (ВНИМАНИЕ!) и не только биологической, может привести к тому, что рассматриваемый объект может начать развиваться не только по законам той первичной эволюции, но и по совсем другим, более быстрым и эффективным. Будут ли это законы другой эволюции — это дело десятое.

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

Поэтому, вот эта фраза

Законы эволюции на кривой кобыле не объедешь. Они объективны.

мягко говоря, являтся ошибочной. Человек законы биологической эволюции объехал и в результате за микроскопический период в 30k-50k лет (по-сравнению с 2kkk лет) стал единолично доминировать на всей планете как биологический вид.

Неясность изложения обычно происходит от путаницы в мыслях.

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

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

IT>>>С помощью речи знания передаются не только от поколения к поколению, но и внутри одного поколения. Соответсвенно развитие вида начинает идти на порядки быстрее и уже отличным от эволиции способам.

Давайте без хамста?
Ещё раз: ваш пример не является контр.

IT>Ну понятно. Ладно, попробуем ещё раз. Сосредоточься и следи за мыслью. Начнём с биологии. Итак, в процессе биологической эволюции человек приобрёл свойство, которое позволило ему развиваться вне рамок биологической революции. Надеюсь с этим ты не будешь спорить. Это показывает, что развитие определённого свойства в процессе эволюции, (ВНИМАНИЕ!) и не только биологической, может привести к тому, что рассматриваемый объект может начать развиваться не только по законам той первичной эволюции, но и по совсем другим, более быстрым и эффективным. Будут ли это законы другой эволюции — это дело десятое.

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

IT>Поэтому, вот эта фраза

IT>

Законы эволюции на кривой кобыле не объедешь. Они объективны.

IT>мягко говоря, являтся ошибочной. Человек законы биологической эволюции объехал и в результате за микроскопический период в 30k-50k лет (по-сравнению с 2kkk лет) стал единолично доминировать на всей планете как биологический вид.

Ну давайте ещё раз. Сто раз разжевал, но видимо никак.

Итак, есть некая система, в этой системе есть некие классы, объекты (экземпляры класса со средой, в которой они находятся) и есть эволюция — функция от класса, среды и объектов в этой среде.
Функция возвращает скорость улучшения класса в данной среде.
Так вот, аксиомы:
1. Количество объектов пропорционально эволюции (не факт, что прямо- или квадратично-)

В природе:
Класс = вид (ДНК)
Объект = представитель вида
Среда = место обитания

В обсуждаемом случае:
Класс = технология и тулзы
Объект = использование
Среда = область использования

Очевидные выводы:
Эволюция тем больше, чем больше объектов.
Эволюция в определённой среде может достигает максимума, возможно локального.
В среде выживают объекты с наибольшой приспособленностью.

Т.о. если вы создаете новый класс (технология, вид...). Изначально его приспособленность 0. Он обязан эволюционировать, для этого объекты этого класса необходимо поместить в некоторую среду. Изначально это "домашний компьютер дяди Васи".
Чтобы повысить скорость эволюции, необходимо увеличивать число объектов. Но так как приспособленность ещё невелика, единственный способ для этого: найти такую среду, где других классов либо не будет, либо они будут убоги.
Можно не повышать скорость эволюции и доводить до ума класс на "домашнем компьютере дяди Васи", но это грозит катастрофическим отставанием. Велика вероятность, что в среде с миллионами объектов других классов (Майкрософт, например), те эволюционируют гораздо быстрее и превзойдут задумки Васи.
Собственно, потому деньги и рулят, что МС отстегнёт мульон, и объектов тут же станет очень много, эволюция пойдёт очень быстро и через год технология превзойдет десятилетний труд Васи.

Теперь по поводу "контрпримера".
В результате эволюции живой системы возник класс, эволюция которого значительно ускорилась (половой отбор).
Затем возник класс, объекты которого смогли влиять на эволюцию своего и других классов.
Это не отменяет того, что чем больше объектов, тем быстрее эволюция (хотя она сделала качественный скачок, теперь она быстрее прежней даже при равном кол-ве объектов). Единственная заковыка — можно влиять на эволюцию других классов.

Замечательно.
Когда вы создадите класс (технологию + тулзы), объекты которых (использования на компах) смогут влиять на эволюцию (скорость улучшения) своего и других классов (т.е. ускорять эволюцию при равном кол-ве объектов), вот тогда и.
Пока этого нет, ваш псевдо-контр-пример не находит аналога в технологиях.
Ваш пример не опровергает законы эволюции, а доказывает, что их не объехать в программировании, хотя в эволюции живых систем уже можно.

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

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

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

В эволюции (компиляторов ЯПов + библиотек + доков), например, качественным скачком может оказаться некий класс (другой ЯП + библиотеки + доки), который будет положительно сказываться на скорости эволюции.
Внимание вопрос — есть ли такой некий класс, который влияет на эволюцию Nemerle и на эволюцию C#? Конечно, это ИДЕ, это другие тулзы и прочее.
Но они одинаковы и там, и там, а потому в сравнении их можно не учитывать. Поэтому определяющих фактором является количество объектов.

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

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

1. Влад сам не раз говорил, что были бы деньги (равносильно — была бы больше популяция, так как больше времени тратилось бы на разработку), дело бы пошло быстрее.
А тут вы утверждаете, что законы эволюции можно объехать. Очень интересно послушать, как при меньшей популяции (читай — меньшем комьюнити и меньшем времени, затрачиваемом на разработку) вы хотите обскакать, например, C#? Внимательно слушаю, какие такие технологии можете применить вы, но не могут они?
2. Там, где используется C#, он по определению лучше приспособлен. Как только Nemerle по этому параметру его начнёт догонять (напомню, что это далеко не мощность языка, это тулзы, доки, гарантии, форумы), МС за пол года выпустит новый C#, превосходяший по параметру "приспособленность". Наиболее простой способ для них будет — включить некие фишки из Nemerle.

2-ой пункт является прямым ответом на удивления Влада в статье, почему сначала МС ничего не хочет, а потом "ворует". Да потому что C# и так был лучшим в своей среде, а как возникла угроза, что его покинут, так как где-то есть суперпупер фишка, то благодаря огромной популяции шарп сэволюционировал в новый, превосходящий конкурентов.

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

VE>А тут вы утверждаете, что законы эволюции можно объехать.

Легко. Но для этого нужны определённые условия.

VE>Очень интересно послушать, как при меньшей популяции (читай — меньшем комьюнити и меньшем времени, затрачиваемом на разработку) вы хотите обскакать, например, C#? Внимательно слушаю, какие такие технологии можете применить вы, но не могут они?

Почему именно я? Возьмём, к примеру, не меня, а Sun. Предположим, что Sun решил объехать MS на козе в войне за девелоперское большинство и расширить линейку своего компилятора современным мощным гибридом. И такой сегодня у Sun почти есть — это Скала. Писк раздуть можно очень громкий и главное этот писк поддержут джависты и прочие сторонники Sun. На сегодняшний день тому же MS ответить будет нечем. F# не в счёт, он не будет принят комьюнити. Нужен привычный язык с новыми крутыми возможностями, способный противостоять Скале. Сегодня достойный стопроцентный вариант только один — Немерле. Проводим несложную операцию по усыновлению и всё, эволюция курит в сторонке.

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

VE>2. Там, где используется C#, он по определению лучше приспособлен. Как только Nemerle по этому параметру его начнёт догонять (напомню, что это далеко не мощность языка, это тулзы, доки, гарантии, форумы), МС за пол года выпустит новый C#, превосходяший по параметру "приспособленность".

Это далеко не так. C# 1.0 появился в 2002-м году, C# 2.0 в 2005-м, C# 3.0 в 2008-м. Следуя этой тенденции, C# 4.0 появится в релизе в 2011 году. Известно, что следующая версия языка в MS готова за несколько лет до релиза. Так же обстоит и с C# 4.0 и уже сегодня известно, что никаких серьёзных изменений в нём не будет. Т.е. кардинальных изменений можно ожидать только в C# 5.0, а это ещё три года. Таким образом у Немерле есть минимум 5! лет, а это очень много.

Неясность изложения обычно происходит от путаницы в мыслях.

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

IT>Почему именно я? Возьмём, к примеру, не меня, а Sun. Предположим, что Sun решил объехать MS на козе в войне за девелоперское большинство и расширить линейку своего компилятора современным мощным гибридом. И такой сегодня у Sun почти есть — это Скала. Писк раздуть можно очень громкий и главное этот писк поддержут джависты и прочие сторонники Sun. На сегодняшний день тому же MS ответить будет нечем. F# не в счёт, он не будет принят комьюнити. Нужен привычный язык с новыми крутыми возможностями, способный противостоять Скале. Сегодня достойный стопроцентный вариант только один — Немерле. Проводим несложную операцию по усыновлению и всё, эволюция курит в сторонке.

Т.е. тут не очевидно, что Sun никого не объезжает, а следует законам эволюции? У него достаточная популяция для быстрой эволюции.
А вот про "усыновление" не понял. МС усыновит Немерле? Ну это один из вариантов, и про него я тоже упоминал, когда говорил, что Немерле может обойти по приспособленности тот же шарп. Только это всё вписывается в законы напрямую, без всяких исключений.

IT>Правдоподобный сценарий? Вполне, если бы в Sun руководство дружило с собственными мозгами, а не сдавало бы год за годом позиции по привлечению на свою сторону девелоперского большинства.

VE>>2. Там, где используется C#, он по определению лучше приспособлен. Как только Nemerle по этому параметру его начнёт догонять (напомню, что это далеко не мощность языка, это тулзы, доки, гарантии, форумы), МС за пол года выпустит новый C#, превосходяший по параметру "приспособленность".

IT>Это далеко не так. C# 1.0 появился в 2002-м году, C# 2.0 в 2005-м, C# 3.0 в 2008-м. Следуя этой тенденции, C# 4.0 появится в релизе в 2011 году. Известно, что следующая версия языка в MS готова за несколько лет до релиза. Так же обстоит и с C# 4.0 и уже сегодня известно, что никаких серьёзных изменений в нём не будет. Т.е. кардинальных изменений можно ожидать только в C# 5.0, а это ещё три года. Таким образом у Немерле есть минимум 5! лет, а это очень много.

Я это привёл как пример. Но не факт, что там в курсе о текущем состоянии Немерла, а когда он выйдет из "подполья" (начнёт массово использоваться), метаться будет поздно.

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

Другое дело, насколько это возможно? Немерле, конечно, превосходит по мощности шарп, но это далеко не всё, что от него нужно.

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

FR>>У высших животных, очень большая часть знаний уже передается через обучение.

IT>Видимо этого пока явно не достаточно.

Для чего?
Многие высшие животные уже не могут выживать если лишить их обучения и коммуникации.

FR>>Угу только речь возникла не на пустом месте. И речь никак ни влияет на биологическое развитие вида.

IT>С этим никто и не спорит. Пока действительно не влияет.

И дальше не будет, разве только косвенно.

FR>>Кстати высшие приматы нормально обучаются речи (язык жестов для глухонемых) и уже самостоятельно обучают ей своих детенышей.

IT>А детёныши своих детёнышей обучают?

Угу, там целая популяция была, еще в начале 90 кажется в знания-сила статьи были.

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

FR>>Не в обход эволюции, просто это свойство позволило начать эволюционировать социальной надсистеме. И сейчас бурно развивается человек ни как биологический вид, а как человеческая цивилизация. Почитай того же Турчина, Моисеева или ТРИЗ.

IT>Это уже совсем другая эволюция.

Это все равно, что сказать, что к примеру СТО которая обобщает классическую механику это совсем другая физика

FR>>Пока не сильно деградирует, скорее наоборот http://txt.newsru.com/world/12dec2007/evolv.html

IT>Я же и говорю, жрать стали больше и лучше, и от этого изменения. Но не думаю, что это мутации преспособления к среде.

А что тогда это?
Неолитическая революция радикально изменила среду, и человек как биологический вид к этому отлично приспосабливается

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

VE>Хотя почему же.
VE>Формально и две обезьяны могут отделиться ото всех, живя в пещере и через 100млн лет выйти людьми. Но будет поздно.
VE>Эволюция среди 100000 обезьян будет идти явно быстрее, чем среди 2.

Не совсем так.
Эволюция, как ни странно, стремится к консервации. Как всё в мире "стремится" к точке равновесия.
(слово "стремится" в кавычках, потому как это просто следствие статистических законов — изменения будут
происходить, пока система в неравновесном состоянии, и не будут происходить, когда система в равновесном
состоянии). Просто эволюция — это способ динамического равновесия. Простейший пример динамического
равновесия — это канатоходец, который должен-бы упасть, но за счёт механизмов обратной связи он
при отклонении в одну сторону смещает центр тяжести в противопложную сторону, и не падает бесконечно
балансируя.
Эволюция — это движение в сторону равновесия, и когда равновесие достигнуто — никакого развития
больше не будет. Но, в отличии от статического равновесия ("кристаллов" — силы связи намного
больше стохастических возмущений; и "газа" — силы свзи намного меньше стохастических возмущений),
динамическое равновесие сравнительно легко теряется. Если силы стохастических возмущений
распределены по нормальному закону (или почти нормальному) — то достаточно скоро для системы
динамического равновесия произойдёт "катастрофа" — внешнее или внутреннее стохастичкое возмущение
выведет её из диапазона, в котором она может сохранять равновесие. То есть подует такой сильный
ветер (или что-то ещё), который наш канатоходец не сможет компенсировать изменением положения точки
тяжести. И он либо упадёт и разобъётся, либо найдёт дополнительный механизм удержания равновесия
(веером помахать, например). Так, стремясь сохранить равновесие, система развивается.
Эволюция среди 100000 обезъян будет идти быстрее в том смысле, что у них больше шансов выжить
при "катастрофах", больше шансов (статистически) найти новый способ удержания равновесия.
Но для этого нужны ещё и условия — наличие этих катастроф. 2 обезъяны могут развиваться
быстрее, если в их пещере чаще случаются "катастрофы", а вне пещеры условия более стабильные.

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

VE>Можно одному ваять что-то, но эволюция будет идти слишком медленно.

Если идёт заполнение новой ниши — то и один будет развиваться очень быстро.

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

M>Не совсем так.
M>Эволюция, как ни странно, стремится к консервации. Как всё в мире "стремится" к точке равновесия.
M>skipped...
Я об этом выше тоже писал. Разумеется, что имеется в виду при прочих равных.

M>Если идёт заполнение новой ниши — то и один будет развиваться очень быстро.
Это уже не один.

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

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

В том, что появление языка привело к появлению другой, не биологической, эволюции.
Развиваются мысли, идеи. Развиваются по тем-же законам, но это другая область, это вообще другое — другой носитель.
Но законы развития для социальной эволюции — такие-же, как и для биологической.
Это вообще просто законы математики. Говорить об отмене законов эволюции — это всё равно, что говорить об отмене законов математики.

IT>>>С помощью речи знания передаются не только от поколения к поколению, но и внутри одного поколения. Соответсвенно развитие вида начинает идти на порядки быстрее и уже отличным от эволиции способам.

Какими "отличными"? Что, перестала действовать конкуренция, перестали действовать правила отбора?
Идеи, или как их обозвал Р.Докинз "мемы", развиваются по тем-же законам, что и ДНК, "гены".

M>>Это тоже эволюция, это тоже процесс развития.

IT>Ну понятно. Ладно, попробуем ещё раз. Сосредоточься и следи за мыслью. Начнём с биологии. Итак, в процессе биологической эволюции человек приобрёл свойство, которое позволило ему развиваться вне рамок биологической революции. Надеюсь с этим ты не будешь спорить. Это показывает, что развитие определённого свойства в процессе эволюции, (ВНИМАНИЕ!) и не только биологической, может привести к тому, что рассматриваемый объект может начать развиваться не только по законам той первичной эволюции, но и по совсем другим, более быстрым и эффективным. Будут ли это законы другой эволюции — это дело десятое.

Так я ж с этим не спорю. Я о том, что для тебя Будут ли это законы другой эволюции — это дело десятое, а я говорю, что это
будет тоже эволюция.

IT>Поэтому, вот эта фраза

IT>

Законы эволюции на кривой кобыле не объедешь. Они объективны.

IT>мягко говоря, являтся ошибочной. Человек законы биологической эволюции объехал и в результате за микроскопический период в 30k-50k лет (по-сравнению с 2kkk лет) стал единолично доминировать на всей планете как биологический вид.

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

Ну позволила социальное развитие (или лучше сказать — психологическое) объехать законы биологической. И что?
Быстро? Это не на долго. Это от того, что система находится в неравновесном состоянии. Да, это неравновесное
состояние длится уже несколько десятков тысяч лет — сравнительно с временем жизни одного человека — очень долго.
Но для данной эволюции — это миг.
Ещё "немного" — может 10, может 100 тысяч лет — и мы прийдём в точку равновесия, и опять миллионы лет
будет постепенное, малозаметное развитие.
Остановка произойдёт к моменту, когда мы не сможем больше наращивать сложность нашего психологического устройства.
С одной стороны — это ещё достаточно далёкий момент (по сравнению с временем жизни одного поколения).
С другой стороны — мы уже близки к пределу — этот предел где-то в районе "уровня бытия Христа/Будды/прочие".
Думаю, к тому времени как человечество достигнет этого предела — вопрос со временем жизни одного индивида
будет решён (спасибо генетике и компьютерам), возможно мы вообще будем способны создавать себе материальный
носитель по мере потребностей. Это позволит людям сосредоточится именно на психологической эволюции.
Вот в этом состоянии и будет медленно и плавно эволюционировать (развиваться) человечество. Если его ещё
можно будет назвать человечеством

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

IT>>Это уже совсем другая эволюция.

FR>Это все равно, что сказать, что к примеру СТО которая обобщает классическую механику это совсем другая физика

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

IT>>Я же и говорю, жрать стали больше и лучше, и от этого изменения. Но не думаю, что это мутации преспособления к среде.

FR>А что тогда это?

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

Неясность изложения обычно происходит от путаницы в мыслях.

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

M>Ошибочной в твоей интерпретации слова "эволюция". Я говорю — законы эволюции (сиречь — математики, статистики) объехать нельзя.

Ну человек же объехал

M>От того, что произшла замена биологической эволюции социальной — ничего не изменилось, эволюция осталась.

Только мамонтов не осталось. Человек их всех съел, вообще нарушил биологический баланс на планете и стал доминировать.

Неясность изложения обычно происходит от путаницы в мыслях.

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

M>http://ru.wikipedia.org/wiki/Теоремы_Гёделя_о_неполноте
И как это относится к тому факту что метод в жабе будет всегда делать то что делал вне зависимости от того какой еще код загружен?
В твоей же системе семантические понятия могут и будут непредсказуемым образом менять друг друга.

WH>>А твой движек который оперирует семантическими понятиями это что?
M>Шаблон. Заготовка. Можно не использовать, написав свою систему типов, свой резолвер имён и пр.
Ну да JVM тоже можно свой ниписать только оно не перестанет быть JVM.

M>И продолжения можно использовать, при определённых условиях — отказаться от аппаратного стека (хранить в хипе), отказаться от предположения о том, что unwinding стека будет происходить всего один раз и т.п.
Бу-га-га.
Либо деструкторы либо многократная раскрутка стека.
Вместе они жить не могут теоритически.

M>Не вижу никакого преимущества.
M>В SymADE можно использовать непротиворечивую модель, а можно использовать и противоречивую модель.
Противоричивой она может стать в любой момент.
Причем это даже не всегда можно будет засечь.
Система просто начнет очень странной глючить.

M>В яве можно использовать только явовскую модель.
M>SymADE шире, он включает в себя всё, что имеет ява, и многое, что ява не имеет.
Например пороблему по сравнения с которой знаменитый DLLHell покажется детским лепетом.

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

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

M>>Ошибочной в твоей интерпретации слова "эволюция". Я говорю — законы эволюции (сиречь — математики, статистики) объехать нельзя.

IT>Ну человек же объехал

М-да... Упрямство, достойное уважения.
Миллиарды лет виды исчезают и появляются. А объехал только человек. Это нечто.
Речь, интеллект, когти, быстрые ноги, возможность летать — свойства. На эволюцию влияют только косвенно, помогая животному выжить и размножиться.
Факторами эволюции они не являются.
Факторы эволюции
1. Мутации и естесственный отбор
Мутаций практически нет. В нас с вами миллиарды копий ДНК, и все они идентичны.
Стопятьсот лет назад эволюция встала в тупик, так как любое животное было достаточно развито, чтобы выжить и родить потомство; естесственный отбор перестал действовать. Немного утрировано, эволюция, конечно, продолжается, но на фоне второго фактора, она практически стоит.
И уже тогда (тогда, а не сейчас у человека) возник новый фактор эволюции
2. Скрешивание (из двух ДНК одна) и половой отбор
Ещё раз — это произошло очень давно и далеко не только у людей. Так что если кто эволюцию и "объехал", то уж точно не человек это сделал первым.

Речь, ещё раз, не является фактором эволюции, она никак не влияет на саму ДНК. Она помогает увеличить популяцию, так же как собакам их скорость реакции и стайность помогли набедокурить в Австралии. Никакого закона эволюции они при этом не обходили.

3. Целенаправленное изменение (и/или создание) ДНК человеком и искусственный отбор.
Самая быстрая эволюция.

Решающую роль играет лишь самый быстрый фактор. На протяжении долгого времени животные эволюционировали под действием 2-го фактора. Они объехали 1-ый фактор, но не саму эволюцию.

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

M>>От того, что произшла замена биологической эволюции социальной — ничего не изменилось, эволюция осталась.

IT>Только мамонтов не осталось. Человек их всех съел, вообще нарушил биологический баланс на планете и стал доминировать.

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

А до этого вымирали виды сами по себе, их никто не вытеснял, да? Или их вытесняли, но не по законам эволюции?

Однополых почти не осталось.
Тасманских дьяволов не осталось.
Динозавров не осталось.

И в каждом, в каждом случае у нас исключение из правил. Вам не кажется это как минимум глупым?

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

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

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

Если честно, то я уже устал возвращать дискуссию в исходную точку и освобождать её от всякой околонаучной шелухи. Тем более, что в качестве ответа я опять услышу что-нибудь из серии "Ну и что, что человек? С ПО такого никогда не случится! Потому что ЭВОЛЮЦИЯ! О!".

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

Неясность изложения обычно происходит от путаницы в мыслях.

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

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

IT>Если честно, то я уже устал возвращать дискуссию в исходную точку и освобождать её от всякой околонаучной шелухи. Тем более, что в качестве ответа я опять услышу что-нибудь из серии "Ну и что, что человек? С ПО такого никогда не случится! Потому что ЭВОЛЮЦИЯ! О!".

То, что ты исказил сейчас мои слова, лишь подтверждает, что сути ты не понимаешь.
Я ни разу не сказал "ну и что, что человек" (в отличие, кстати, от твоих слов "ну и что, что эволюция, а вот человек!"). Я говорил, что "человек ничего и никого не объехал", так же, как и все остальные животные. Он доминирут по всем законам, он получил качество в результате эволюции, он применил его, он стал доминироать; а не благодаря хитросплетениям и исключениям.
Хотя, видимо, тебе эти законы именно танцами с бубном и кажутся, а не закономерностью.

Ты упорно приводишь в качестве "объезда" то, что этим не является. Настолько упорно, что мне даже завидно.
Я уже раз сто сказал, раз 10 выделил, что ни речь, ни какие-либо ещё качества человека не обходят законов эволюции. И что я слышу?
Ни одного аргумента, ни одного опровержения моих слов или кого ещё, а методичные повторения, как мантры:
"А человеку удалось

", "Человек объехал эволюцию", "Человек получил качество и теперь доминирует на планете"

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

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

Законы развития технологий и внедрения новых идей (да что уж там, законы развития Вселенной, фигли) на кривой кобыле не объедешь. Они объективны.
Вот разберись с этими законами, и не надо будет плакаться, ты будешь знать, почему так происходит. И иногда даже сможешь придумать, как эти законы использовать с пользой для себя.

Абсолютно верная фраза. Если камень падает вниз, то значт есть такой закон. Его лишь можно открыть и изучить. Если МС не принимает новый идеи, значит система развивается по определённому закону, который этому препятствует. Его лишь можно изучить.
Объехать его нельзя, он абсолютен.

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

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

VE>Законы развития технологий и внедрения новых идей (да что уж там, законы развития Вселенной, фигли) на кривой кобыле не объедешь. Они объективны.
VE>Вот разберись с этими законами, и не надо будет плакаться, ты будешь знать, почему так происходит. И иногда даже сможешь придумать, как эти законы использовать с пользой для себя.

согласен

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

согласен

VE>Если МС не принимает новый идеи, значит система развивается по определённому закону, который этому препятствует.

согласен

VE>Его лишь можно изучить.
VE>Объехать его нельзя, он абсолютен.

не согласен. Если под камень можно подложить пороховой заряд и он полетит туда куда нам надо, а не только вниз (причем в точном соответствии с законами), то наверно можно что-то подложить и под МС, чтоб она тоже поехала в нужном направлении не нарушая законов эволюции

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

как-то так

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

VE>>Его лишь можно изучить.
VE>>Объехать его нельзя, он абсолютен.

OE>не согласен. Если под камень можно подложить пороховой заряд и он полетит туда куда нам надо, а не только вниз (причем в точном соответствии с законами), то наверно можно что-то подложить и под МС, чтоб она тоже поехала в нужном направлении не нарушая законов эволюции

Это не объезд, это использование. Законы этого мира в этом мире абсолютны. Их можно только изучать, и использовать.
Никогда физики не ставят под сомнение то, что происходит в мире, под сомнение ставят их понимание этого явления, их теории, их расчёты, их измерения, но не сам факт.

Так что сама фраза "законы эволюции были объеханы человеком" — это, мягко говоря, оксюморон.

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

FR>>Это все равно, что сказать, что к примеру СТО которая обобщает классическую механику это совсем другая физика

IT>Терория антен изучает излучения в ближней, средней и дальней зонах, которые описываются тремя разными способами. Излучение одно, а физики разные. Прикольно, да? А ещё закон Ома, который мы все проходили в школе имеет отклонения на высоких частотах. Закон как бы один, да физика в разных условиях у него разная.

Закон Ома это частный случай, уравнения Максвелла уже будут работать на любых частотах, есть и более общая квантовая электродинамика. Так и биологическая эволюция тоже частный случай.

FR>>А что тогда это?

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

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

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

IT>Только мамонтов не осталось. Человек их всех съел, вообще нарушил биологический баланс на планете и стал доминировать.

Аэробные бактерии гораздо круче человека

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

VE>Так что сама фраза "законы эволюции были объеханы человеком" — это, мягко говоря, оксюморон.

насчет терминологии эволюция/неэволюция, это вы с IT обсуждайте

Я из твоих умозаключений увидел однозначно неправильный вывод:

>Если МС не принимает новый идеи, значит система развивается по определённому закону, который этому препятствует. Его лишь можно изучить.
>Объехать его нельзя, он абсолютен.

то что есть закон всемирного тяготения, не означает, что камни могут только падать вниз, есть и другие законы и камень может полететь вверх, если его хорошенько пнуть. Точно также то, что есть какой-то закон по которому МС тормозит на 3 года не означает что не существует других, по которым этот срок может быть уменьшен до 0,5 года. А уж назвать это "объехать" или "изучить, и использовать" — мне обсуждать неинтересно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

OE>Точно также то, что есть какой-то закон по которому МС тормозит на 3 года не означает что не существует других, по которым этот срок может быть уменьшен до 0,5 года.

а) Почему надо MS ускорять? Вам новые технологии, или чтоб они именно от MS исходили? У MS и так всё хорошо, прибыли они получают, негативных тенденций не замечено. Зачем им внедрять новые технологии?
б) Почему вы решили, что Nemerle или какая-то другая технология — лучше и прогрессивней, чем та, которую толкает MS? От того, что она её лет через 10 сама реализует? Так 10 лет — это большой срок. Сейчас это технология, которая хуже, а через 10 лет условия изменятся и она станет лучше. Вот к тому времени её и реализуют. Попробуйте "прогрессивный" .NET запустить на 386 компе с 4 мегами памяти, сразу обнаружиет степень его прогрессивности на тот момент, когда такой комп был вершиной технологии десктопов.

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

OE>>Точно также то, что есть какой-то закон по которому МС тормозит на 3 года не означает что не существует других, по которым этот срок может быть уменьшен до 0,5 года.

M>а) Почему надо MS ускорять?

я просто оспаривал сформулированный выше тезис: "МС тормозит — значит есть такой закон — а закон отменить нельзя". Насколько я понял Влада, его колбасит именно от последовательности "отрицание, замалчивание, пиар, реализация, популяризация"

M>б) Почему вы решили, что Nemerle или какая-то другая технология — лучше и прогрессивней, чем та, которую толкает MS? От того, что она её лет через 10 сама реализует?

ну, если оставаться в рамках обсуждаемой статьи — то да

M>Так 10 лет — это большой срок. Сейчас это технология, которая хуже, а через 10 лет условия изменятся и она станет лучше. Вот к тому времени её и реализуют. Попробуйте "прогрессивный" .NET запустить на 386 компе с 4 мегами памяти, сразу обнаружиет степень его прогрессивности на тот момент, когда такой комп был вершиной технологии десктопов.

аналогия не катит, для Nemerle не нужен 986 комп со 128 ядрами, ему хватает столько же, сколько и C#-у

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Кстати, всегда было интересно, как в США запрещают публикции по определённой тематике. Ведь среда там типа либеральнее.
Элементарно, Ватсон. Вам просто предложат перейти на работу в закрытое учреждение, где вы будете заниматься тем же самым, только за деньги и молча. Захочется паблисити — добро пожаловать обратно, на вольные хлеба.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

ANS>>Кстати, всегда было интересно, как в США запрещают публикции по определённой тематике. Ведь среда там типа либеральнее.
S>Элементарно, Ватсон. Вам просто предложат перейти на работу в закрытое учреждение, где вы будете заниматься тем же самым, только за деньги и молча. Захочется паблисити — добро пожаловать обратно, на вольные хлеба.

А если я "идейный" и откажусь?

http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>А если я "идейный" и откажусь?
У тебя найдут детское порно.

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

OE>Насколько я понял Влада, его колбасит именно от последовательности "отрицание, замалчивание, пиар, реализация, популяризация"

Так это вообще просто. Корпорация большая, там много людей, там свои движения — один говорит "это не нужно", другой говорит "это рулёз".
Кто сейчас у руля развития C# — тот и есть мнение MS. Завтра этого человека поменяют, или он столкнётся с задачей где
"это рулёз", или их задавят жалобы пользователей которые хотят "именно этого рулёза", или вице-президент какой услышит по радио, что
"это рулёз" и намекнёт главе разработчиков C# какова сейчас политика партии — и мнение резко изменилось.
Конкретно эта последовательность вообще к судьбе прогресса отношения не имеет. Стохастические флуктуации.

OE>аналогия не катит, для Nemerle не нужен 986 комп со 128 ядрами, ему хватает столько же, сколько и C#-у

Нельзя же так примитивно. Я привёл пример, который прост для понимания и демонстрирует почему рулёз сейчас и рулёз через 10 лет — это разные вещи.
Что до мета-программирования вообще, и Nemerle в частности — почему MS вообще должна развивать мета-программирование? Они туда бабахнут
много денег, а прибыли не получат, например. Может им лучше деньги вложить в F#, или какой Ruby#. Одно дело написать бету компилятора,
а другое дело сделать из него полноценный компилятор, с поддержкой всех MSовских средств разработки и т.п.
Сколько времени они Vist-у делали? И половину из обещанных фич не сделали. А у них же там лучшие программисты сидят.
MS и так уже упёрлась в предел сложности программного обеспечения, они не могут себе позволить совать в .NET всё подряд — иначе
следующая версия не через 3 года выйдет, а через 30.

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

V>Знаешь, Влад, когда я учил яву, я тоже много сокрушался по поводу отсутствия того или иного вида синтаксического сахара. Юзинга нет или еще чего — как люди вообще могут писать программы на яве, я понять не мог. Но вот когда дело дошло до решения конкретных проблем предметной области, проблемы языка сразу стали несущественными. 95% mainstream-программистов сильно начхать на эти "приятные мелочи", ибо они "живут" в своей предметной области и почти все проблемы, с которыми им приходится сталкиваться — это проблемы предметной области для которых возможный выигрыш от "приятные мелочей" ничтожен. Прикладной программист не бьется над проблемой, как вызвать метод: через рефлексию, или динамический сахар? Он бьется скорее над поиском: какой метод вызвать, когда вызвать, с какими параметрами вызвать и что делать с результатом. Как видишь, в решении реальных проблем, с которыми сталкиваются прикладные программисты, синтаксический сахар помогает слабо, ибо он лишь помогает ответить на вопрос "Как сделать?", но он ни на сантиметр не приближает к ответу на "Что делать?". А основополагающий вопрос — это именно второй. Вот лично мне почти плевать на эти новые языковые фичи, так как они помогают лишь в решении мелких тактических задачек, которые и раньше решались совершенно без сколько-нибудь существенных трудозатрат.

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

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

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

O>Влад, у меня есть новая идея. Хотите? Пронаблюдайте за ее судьбой.

Хочу, если она действительно нова.

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

>>Если МС не принимает новый идеи, значит система развивается по определённому закону, который этому препятствует. Его лишь можно изучить.
>>Объехать его нельзя, он абсолютен.

OE>то что есть закон всемирного тяготения, не означает, что камни могут только падать вниз, есть и другие законы и камень может полететь вверх, если его хорошенько пнуть. Точно также то, что есть какой-то закон по которому МС тормозит на 3 года не означает что не существует других, по которым этот срок может быть уменьшен до 0,5 года. А уж назвать это "объехать" или "изучить, и использовать" — мне обсуждать неинтересно.

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

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

FR>Закон Ома это частный случай, уравнения Максвелла уже будут работать на любых частотах, есть и более общая квантовая электродинамика. Так и биологическая эволюция тоже частный случай.

Просто мы ещё не знаем и не понимаем всей картины. Правильно?

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

Неясность изложения обычно происходит от путаницы в мыслях.

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

VE>То, что ты исказил сейчас мои слова, лишь подтверждает, что сути ты не понимаешь.
VE>Я ни разу не сказал "ну и что, что человек" (в отличие, кстати, от твоих слов "ну и что, что эволюция, а вот человек!"). Я говорил, что "человек ничего и никого не объехал", так же, как и все остальные животные. Он доминирут по всем законам, он получил качество в результате эволюции, он применил его, он стал доминироать; а не благодаря хитросплетениям и исключениям.

Мда, всё так хорошо начиналось, а закончилось так банально.

VE>Хотя, видимо, тебе эти законы именно танцами с бубном и кажутся, а не закономерностью.

Ладно, давай попробуем по твоим правилам, всё равно это сути не меняет. Итак, всё можно объяснить законами эволюции единой и неделимой, хотя мне проще было бы иметь несколько разных. Но не суть. Бактери — эволюция, человек — эволюция, столкнулись с кометой — эволюция, прилетели инопланетяне — эволюция, Майкрософт захотел — эволюция, Майкрософ НЕ захотел — тоже эволюция. Всё можно объяснить с точки зрения законов эволюции. Есть только одна проблема. То что мы уже знаем объяснить можно, а вот то до чего мы ещё не доросли ни объяснить, ни предсказать нельзя, иначе бы мы давно знали правду о будущем.

Поэтому вернёмся ещё раз в начальную точку.

VE>

VE>Законы эволюции на кривой кобыле не объедешь. Они объективны.
VE>Вот разберись с этими законами, и не надо будет плакаться, ты будешь знать почему так происходит. И иногда даже сможешь придумать как эти законы использовать с пользой для себя.

VE>Законы развития технологий и внедрения новых идей (да что уж там, законы развития Вселенной, фигли) на кривой кобыле не объедешь. Они объективны.
VE>Вот разберись с этими законами, и не надо будет плакаться, ты будешь знать, почему так происходит. И иногда даже сможешь придумать, как эти законы использовать с пользой для себя.

VE>Абсолютно верная фраза. Если камень падает вниз, то значт есть такой закон. Его лишь можно открыть и изучить. Если МС не принимает новый идеи, значит система развивается по определённому закону, который этому препятствует. Его лишь можно изучить.
VE>Объехать его нельзя, он абсолютен.

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

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

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

Неясность изложения обычно происходит от путаницы в мыслях.

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

VE>Это не объезд, это использование. Законы этого мира в этом мире абсолютны. Их можно только изучать, и использовать.
VE>Никогда физики не ставят под сомнение то, что происходит в мире, под сомнение ставят их понимание этого явления, их теории, их расчёты, их измерения, но не сам факт.

Вот золотые слова! Защитникам теории эволюции осталось теперь только внимательно в них вдуматься.

VE>Так что сама фраза "законы эволюции были объеханы человеком" — это, мягко говоря, оксюморон.

Почему? Эволюция биологических видов на Земле была похерена и ценично растоптана человеком. Это факт. Или всё же мамонты вымерли из-за нарушения душевного равновесия?

Неясность изложения обычно происходит от путаницы в мыслях.

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

VE>Я написал "если камень падает вниз, значит есть определенный закон, по которому это происходит."
VE>А вы мне отвечаете "если есть закон, что камень падает вниз, это не значит, что его нельзя кинуть вверх".
VE>Я это отрицал? Можно, только закон надо сначала изучить, и первое утверждение от этого неверным не становится.

Но и не отрицает возможность полёта камня как вверх, так и в любую другую сторону. Так?

Неясность изложения обычно происходит от путаницы в мыслях.

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

VE>>Законы этого мира в этом мире абсолютны. Их можно только изучать, и использовать.

CU>Ересь. Или неправильное использование понятий.

Скорее непонимание самоограниченности.

Неясность изложения обычно происходит от путаницы в мыслях.

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

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

VE>>Это не объезд, это использование. Законы этого мира в этом мире абсолютны. Их можно только изучать, и использовать.
VE>>Никогда физики не ставят под сомнение то, что происходит в мире, под сомнение ставят их понимание этого явления, их теории, их расчёты, их измерения, но не сам факт.

IT>Вот золотые слова! Защитникам теории эволюции осталось теперь только внимательно в них вдуматься.

VE>>Так что сама фраза "законы эволюции были объеханы человеком" — это, мягко говоря, оксюморон.

IT>Почему? Эволюция биологических видов на Земле была похерена и ценично растоптана человеком. Это факт. Или всё же мамонты вымерли из-за нарушения душевного равновесия?

Вымирали далеко не только мамонты, и далеко не только из-за человека.
Даже если учесть, что мы до сих пор не знаем всех законов эволюции; то, как именно человек стал доминировать, вписывается в уже существующие.
Я так и не понял, что человек сделал такого, чего не делали до него? Ты же не отрицаешь что люди изменялись и получили свойство. Ты не отрицаешь, что речь и интеллект помогли им быть сильнее. Ты не отрицаешь, что, воспользовавшись этим, они заселили планету. Но при этом ты считаешь, что эволюция была похерена человеком.
Ну вот появился бы могучий лев. Тупой, брутальный, но очень сильный. Пошёл бы и сожрал тогда ещё не очень разумных людей, сожрал бы насекомых, травоядных, растения, заселил бы планету. По-твоему это означало бы, что эволюция видов была бы им похерена?
Более того, человек _не_ доминирует. Он живет только на суше, хотя и может с помощью приспособлений плавать под водой. Сравнить же "возможность уничтожить всех остальных" сложно хотя бы потому, что для этого необходимо одно маленькое, но веское условие. Весь вид должен захотеть уничтожить остальных, а это ещё доказать надо, что это вообще возможно. Может, другая половина человечества в такой ситуации запротестует и люди уничтожат лишь сами себя.

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

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

VE>>Я написал "если камень падает вниз, значит есть определенный закон, по которому это происходит."
VE>>А вы мне отвечаете "если есть закон, что камень падает вниз, это не значит, что его нельзя кинуть вверх".
VE>>Я это отрицал? Можно, только закон надо сначала изучить, и первое утверждение от этого неверным не становится.

IT>Но и не отрицает возможность полёта камня как вверх, так и в любую другую сторону. Так?

Да. Вернемся к исходному утверждению снова?
"Законы эволюции на кривой кобыле не объедешь"
Ты что понимаешь под эволюцией? Теорию, написанную человеком, или само явление?
Если теорию, то разумеется, человек может ошибаться.
Если само явление, то законы физики обойти нельзя, даже если они ещё не открыты и не изучены.

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

VD>Хочу, если она действительно нова.

Спасибо за интерес. Свяжетесь со мной по аське, чтобы обсудить ее новизну?
#41234911восемь

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>А если я "идейный" и откажусь?

До начала 1990-х Фишер уединённо жил в Пасадине (Калифорния), не появляясь на публике. Про него уже практически забыли, когда в 1992 югославский банкир Е. Василевич предложил Фишеру организовать коммерческий матч-реванш с Б. В. Спасским и экс-чемпион неожиданно согласился. Призовой фонд матча составил 5 миллионов долларов США. Матч проходил на острове Свети-Стефан в Югославии, на условиях, выдвигавшихся ранее Фишером для матча с Карповым: до 10 побед. Фишер победил со счётом 10:5, всего было сыграно 30 партий.

...

После победы в матче к Фишеру предъявили претензии налоговое ведомство и Госдеп США, обвинившие Фишера в нарушении международного эмбарго (бойкота Югославии, объявленного США) и уклонении от уплаты налогов. По первому пункту ему грозило до 10 лет тюрьмы, по второму — штраф в 250 тысяч долларов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>

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

IT>>Тупая часть стада пойдёт туда, куда его погонят. Это так, но речь сейчас вовсе не об этом. Речь о погонщиках стада, а у них всегда есть выбор куда его гнать.

V>Ты путаешь цель и инструмент для достижения цели.

В каком конкретно месте я это делаю?

Неясность изложения обычно происходит от путаницы в мыслях.

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

N>Является ли профессор, вычисляющий дифуры на древнем Фортране, частью "тупого стада"?

При чём тут профессор? Речь идёт о 95% бузинес программистов. Если не веришь мне уточни у prVovik, это его мысль.

Неясность изложения обычно происходит от путаницы в мыслях.

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

VE>Вымирали далеко не только мамонты, и далеко не только из-за человека.

На сомом деле, всё это к делу не относится. Главное, что эта теория не гарантирует ни положительного, ни отрецательного исхода событий ни для какого-либо ПО, ни для чего-либо ещё. А следовательно использовать её в качестве аргумента бессмысленно.

Неясность изложения обычно происходит от путаницы в мыслях.

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

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

VE>>Вымирали далеко не только мамонты, и далеко не только из-за человека.

IT>На сомом деле, всё это к делу не относится. Главное, что эта теория не гарантирует ни положительного, ни отрецательного исхода событий ни для какого-либо ПО, ни для чего-либо ещё. А следовательно использовать её в качестве аргумента бессмысленно.

Ты не игнорируй, пожалуйста.
"Законы эволюции на кривой кобыле не объедешь"
Что ты понимаешь под эволюцией? Теория, писаная человеком; или явление?

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

VE>Что ты понимаешь под эволюцией? Теория, писаная человеком; или явление?

Мне без разницы. Думаю, что ты хочешь услышать от меня явление

Неясность изложения обычно происходит от путаницы в мыслях.

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

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

VE>>Что ты понимаешь под эволюцией? Теория, писаная человеком; или явление?

IT>Мне без разницы. Думаю, что ты хочешь услышать от меня явление

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

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

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

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

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

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

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

V>Конечно, язык тоже влияет на поддерживаемость, и спорить с этим глупо. Но мне кажется, что некоторые участники данного форума сильно преувеличивают значение языка программирования

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

Один мой давний начальник любил говорить, что качество/сложность продукта не может превышать на порядок качество/сложность инструмента, с помощью которого он сделан. Так вот получается, что улучшение инструмента, допустим, на 5% позволяет делать продукт, который на 50% процентов качественнее/сложнее при тех же затратах

Неясность изложения обычно происходит от путаницы в мыслях.

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

VE>Я написал "если камень падает вниз, значит есть определенный закон, по которому это происходит."
VE>А вы мне отвечаете "если есть закон, что камень падает вниз, это не значит, что его нельзя кинуть вверх".
VE>Я это отрицал? Можно, только закон надо сначала изучить, и первое утверждение от этого неверным не становится.

а не было там второй части, было только:

Абсолютно верная фраза. Если камень падает вниз, то значт есть такой закон. Его лишь можно открыть и изучить. Если МС не принимает новый идеи, значит система развивается по определённому закону, который этому препятствует. Его лишь можно изучить.
Объехать его нельзя, он абсолютен.

из чего явно следовало, что камни вверх не летят, МС тормозит, и будет так во веки веков, аминь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

V>>Количество строк кода не является критерием поддерживаемости.

AVK>Является. Хотя, конечно, критерий этот далеко не единственный и даже не самый важный.

Ой, я это и имел ввиду, просто некорректно выразился. Там дальше мысль развивается.

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

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

И как решает этот случай наша некая прогрессивная технология? (которую, к примеру, MS обзывает неинтересной).

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

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

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

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

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

M>И как решает этот случай наша некая прогрессивная технология? (которую, к примеру, MS обзывает неинтересной).

Не понял, какой случай?

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

M>Фреймворк сам по себе — зависит от языка, от платформы.

От платформы. Язык не причем. Языков может быть много, а платформа с фреймворком одни.

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

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

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

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

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

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

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

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

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

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

V>как не замечаешь баннеры с рекламой на веб-страницах.
Это другое.
Банеры всегда весят в одном месте.
А в данном случае банеры висят черед каждое слово.

... << RSDN@Home 1.2.0 alpha rev. 745>>

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

M>>И как решает этот случай наша некая прогрессивная технология? (которую, к примеру, MS обзывает неинтересной).

V>Не понял, какой случай?

Какая новая технология позволит решить проблему противоречия между краткостью и понятностью кода?
Скажем, мета-программирование, и Nemerle в частности — решают эту проблему?
А другие средства для решения этой проблемы есть?
Если есть — то какие? Если нет — то какие надо создать? Если мы их создадим — будет ли нам счастье,
в том числе и реализует ли её MS или нет?

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

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

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

Возможность передать замыкание (closure) в контейнер.
Возможность повесить код (обработчик) на событие в GUI (скажем, на нажатие кнопки).
Возможность определить тип данных в runtime (instanceof и т.п.).
Возможность инкапсуляции, наследования, полиморфизма (ООП).
И многое многое другое.
Скажешь, фреймворк не будет зависить от наличия этих возможностей в языке/платформе?

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

O>Спасибо за интерес. Свяжетесь со мной по аське, чтобы обсудить ее новизну?
O>#41234911восемь

У меня нет аськи. Есть МСН, есть Скайп и мыло.

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

V>В общем, это созвучно древним флеймам из С++, что лучше: написать простенький цикл руками, или использовать алгоритмы из STL. Первый вариант "очевидный", а второй "лаконичный". Какой из них "правильный" — сказать сложно. Короче, это я к тому, что уменьшение количества строк кода еще не означает однозначное улучшение поддерживаемости. Соответствующий пример привести не сложно. Думаю, ты и сам можешь

Чушь это. Это спор с блабами. Код использующий СТЛ не очевиден только тем кто не удостужился изучить СТЛ или даже лежащие в его основах принципы. Конечно сам СТЛ довольно кривое порождение, так как делался в рамках С++ и человеком сознание которого было под большим влиянием С++, но тем неменее базис у него очень даже логичный и стройный — лямбда-исчисления (т.е. математика и ФП).

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

M>Такой, что точно так-же динамические скриптовые языки (вроде PHP) заняли нишу в которой раньше доминировали ява, С и пр.
M>Принцип тот-же.

ПХП занял нишу где раньше доминировал АСП (не нэт). И не нишу, а поднишу — "создание сайтов для домохозяек".

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

M>Возможность передать замыкание (closure) в контейнер.
M>Возможность повесить код (обработчик) на событие в GUI (скажем, на нажатие кнопки).
M>Возможность определить тип данных в runtime (instanceof и т.п.).
M>Возможность инкапсуляции, наследования, полиморфизма (ООП).
M>И многое многое другое.
M>Скажешь, фреймворк не будет зависить от наличия этих возможностей в языке/платформе?

Я имел ввиду, какую сейчас фичу можно добавить в язык, так чтобы она оказала серьезное влияние на фреймворк.

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

M>Какая новая технология позволит решить проблему противоречия между краткостью и понятностью кода?

Фишка в том, что эта проблема сейчас не стоит перед мейнстримом. Во всяком случае остро. С#-а пока для бизнес-задач хватает — на замену VB6.

M>Скажем, мета-программирование, и Nemerle в частности — решают эту проблему?

Лично мне больше нравится выделенный, не смешиваемый с основным кодом DSL, с четко определенными границами и точками соприкосновения с основным кодом.

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

VD>Чушь это. Это спор с блабами. Код использующий СТЛ не очевиден только тем кто не удостужился изучить СТЛ или даже лежащие в его основах принципы. Конечно сам СТЛ довольно кривое порождение, так как делался в рамках С++ и человеком сознание которого было под большим влиянием С++, но тем неменее базис у него очень даже логичный и стройный — лямбда-исчисления (т.е. математика и ФП).

Тем не мениее флеймы на эту тему возникали(ют) постоянно, и вовсе не от незнания STL. Хорошо, возьми вместо STL что-нибудь из Александреску. Компактно? Компактно! Очевидно? Ну разве что после поллитры. Хотя ладно, тут опять можно съехать на том, что С++ кривой. Давай представим, что настало счастливое будущее. Nemerle покорил мир. Некто Jagadheeswaran получает задание пофиксить баг на web-страничке. Документации, естественно, нет. Людей, которые это писали, конечно, тоже. Открывает он код странички — а там хитросплетение макросов. Что тут делается — непонятно, поэтому Jagadheeswaran заглядывает в код макроса. В коде макроса выполяются какие-то мутные операции с AST. В итоге он должен понять, что тут происходит с AST, потом вернуться обратно, выполнить в уме преобразование AST, представить, какой будет результирующая программа и, наконец, найти в этой виртуальной программе ошибку. Про отладку я вообще молчу. Вот это и есть неочевидный код.

prVovik,

M>>Скажешь, фреймворк не будет зависить от наличия этих возможностей в языке/платформе?

V>Я имел ввиду, какую сейчас фичу можно добавить в язык, так чтобы она оказала серьезное влияние на фреймворк.

Добавляем требование к языку "отныне все функции обязаны быть чистыми для пользователя". Всё — фрейморк подлежит полнейшей переделке. Да и вообще, все библиотеки, вплоть до стандартной.

Ещё примеры — виртуальные классы, структурные типы, макросы, продолжения. (В предположении, что фреймворк джавовский)

— Виртуальные классы приводят к тотальному пересмотру всех иерархий классов.
— Структурные типы делают интерфейсы необязательными, статическая типизация сохраняется, но даункасты уже невозможны.
— Макросы позволяют выставлять наружу DSL, а не просто набор методов.
— Продолжения позволяют реализовать все управляющие конструкции в библиотеке. Сравни веб-фреймворки использующие продолжения, и не использующие их — различия весьма существенны (и для прикладного программиста, и для разработчика фреймворка).

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

LCR>Добавляем требование к языку "отныне все функции обязаны быть чистыми для пользователя". Всё — фрейморк подлежит полнейшей переделке. Да и вообще, все библиотеки, вплоть до стандартной.

Фантастика. Фреймворк императивный по своей сути, как и все МС-овские языки под него. Это равнозначно созданию новой другой платформы. МС сейчас на это не пойдет. Я мел ввиду реальный варианнт, а не фантасический.

LCR>Ещё примеры — виртуальные классы, структурные типы, макросы, продолжения. (В предположении, что фреймворк джавовский)
LCR>- Виртуальные классы приводят к тотальному пересмотру всех иерархий классов.

Что ты имеешь ввиду под "виртуальным классом"?

LCR>- Структурные типы делают интерфейсы необязательными, статическая типизация сохраняется, но даункасты уже невозможны.

А ради чего все это?

LCR>- Макросы позволяют выставлять наружу DSL, а не просто набор методов.

Это только при условии, что на фреймворке живет один единственный язык программирования.

LCR>- Продолжения позволяют реализовать все управляющие конструкции в библиотеке. Сравни веб-фреймворки использующие продолжения, и не использующие их — различия весьма существенны (и для прикладного программиста, и для разработчика фреймворка).

В ASP.NET'e и так управляющие конструкции реализованы в библиотеке.

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

S>Вот этот момент мне непонятен. Что есть "хитросплетение макросов"? Вот прикинь, он открывает сейчас код странички, а там какие-то мутные using(), foreach() и т.п.

using() и foreach() стандартны.

S>Неужто для отладки он должен понять, во что раскрывается паттерн foreach, потом скомпилировать это в уме в MSIL, потом отджиттить, и только после этого исправить ошибку?

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

S>Скорее всего, если код не написан другим Джагадхисвараном,
это слишком смелое предположение.

S>там нормальный код на читаемом языке.
Это не важно. Главное, что эти действия "ни о чём"

S>А вот улучшить могут. Потому, что к примеру вместо лапши из вызовов IDispatch на две страницы написан банальный
S>

lazy Workbook.Sheets[1].Range("A1:A12").Formatting.BackColor=Color.Green;

А других вариантов нет? Либо лапша на 2 страницы из вызовов IDispatch, либо макрос?

S>Да, в коде макроса lazy происходят мутнейшие операции с AST. Тем не менее, выполнять их не нужно. Потому что сразу же виден источник ошибки: вставили новый столбец, и надо исправить диапазон на B1:B12.
S>Вот это и есть очевидный код.

Вот незадача, а мы не вставляли новый столбец, а оно всеравно падает

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

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

S>Как раз важно, потому что если код читаемый, то всё понятно. Если нечитаемый, то непонятно.

Не, не так. Если код читаемый, то понять легче, если нечитаемый, то сложнее.

S>>>А вот улучшить могут. Потому, что к примеру вместо лапши из вызовов IDispatch на две страницы написан банальный
S>>>

lazy Workbook.Sheets[1].Range("A1:A12").Formatting.BackColor=Color.Green;

V>>А других вариантов нет? Либо лапша на 2 страницы из вызовов IDispatch, либо макрос?
S>Ну, либо поддержка lazy встроенная в язык, как это сделано в Delphi. И, если не ошибаюсь, в VB.

Гхм. Пардон. lazy — это ленивые вычисления, или что? Если ленивые вычисления, то как они связаны с IDispatch?

S>Почему фиг? Поставишь брекпоинт, как обычно, и посмотришь через Watch или Immediate, что происходит.
Падает где-то в коде, сгенерированным макросом.

S>Ребята, все эти ужоснахи происходят от какой-то боязни всего. Любой инструмент для упрощения кода можно применять для его запутывания. Вот, к примеру, вызов процедуры — страшное оружие в опытных руках. Достаточно выбрать неудачные имена, попользовать ref параметры, сделать трактовку возвращаемых результатов понетривиальней и всё, приплызд. Никто потом не разберется.
S>Да одной арифметики хватит для того, чтобы всё запутать до нераспутываемости!

Наверное, это от того, что у всех разный опыт. Мне несколько раз приходилось занимаься реанимацией проектов, разрабатывавшихся и проваленных индусами. Дак вот, ответственно заявляю: Слава БОГУ, что у этих индусов не было макросов!!!!

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

VD>>Сдается мне, что непонимашь тут все же ты.

V>Не понимаю что?

Величия Немерле и его Автора.

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

V>Гхм. Пардон. lazy — это ленивые вычисления, или что? Если ленивые вычисления, то как они связаны с IDispatch?
Тьфу, блин, опечатался. Макрос late, конечно же. Это late binding через IDispatch.
V>Падает где-то в коде, сгенерированным макросом.
Гм. Еще раз поясняю: вот сейчас падает где-то в нативном коде, сгенерированном джитом по мсилу, сгенерированному шарпом по коду, в который разворачивается синтаксический сахар. И как, тебе это когда-то мешало отлаживать джаву или шарп?

V>Наверное, это от того, что у всех разный опыт. Мне несколько раз приходилось занимаься реанимацией проектов, разрабатывавшихся и проваленных индусами.
Мне тоже.
V> Дак вот, ответственно заявляю: Слава БОГУ, что у этих индусов не было макросов!!!!

Ответственно заявляю: макросы хуже не сделают.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>Тьфу, блин, опечатался. Макрос late, конечно же. Это late binding через IDispatch.
Ну если не лень было писать макрос, то что помешает написать динамическую обертку типа:
Dynamic(LoadExcelCOM()).["Workbook"].["Sheets"].[1].["Range"].["A1:A12"].["Formatting"].["BackColor"] = Color.Green;
?

И никакой лапши на 2 страница. При этом все отлично отлаживается.

V>>Падает где-то в коде, сгенерированным макросом.
S>Гм. Еще раз поясняю: вот сейчас падает где-то в нативном коде, сгенерированном джитом по мсилу, сгенерированному шарпом по коду, в который разворачивается синтаксический сахар. И как, тебе это когда-то мешало отлаживать джаву или шарп?

Можешь привести пример такого падения, а то у меня что-то фантазия сегодня не работает.

V>> Дак вот, ответственно заявляю: Слава БОГУ, что у этих индусов не было макросов!!!!

S>Ответственно заявляю: макросы хуже не сделают.
Ох, твоими бы устами

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

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

S>>Тьфу, блин, опечатался. Макрос late, конечно же. Это late binding через IDispatch.
V>Ну если не лень было писать макрос, то что помешает написать динамическую обертку типа:
V>Dynamic(LoadExcelCOM()).["Workbook"].["Sheets"].[1].["Range"].["A1:A12"].["Formatting"].["BackColor"] = Color.Green;
V>?
Макрос пишется 1 (один) раз на все комы. В качестве упражнения попробуй сделать свой динамик, да еще так, чтобы он работал

V>И никакой лапши на 2 страница. При этом все отлично отлаживается.
Никакой разницы с отладкой макроса здесь, естественно, не будет.
V>>>Падает где-то в коде, сгенерированным макросом.
S>>Гм. Еще раз поясняю: вот сейчас падает где-то в нативном коде, сгенерированном джитом по мсилу, сгенерированному шарпом по коду, в который разворачивается синтаксический сахар. И как, тебе это когда-то мешало отлаживать джаву или шарп?

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

VE>Но если бы так все писали, было бы счастье. А вот если в написанный кем-то давно макрос закралась ошибка...
VE>Но с другой стороны, эта ситуация не особо хуже, чем когда в написанную кем-то давно простую функцию закралась ошибка.
Именно. Учтем, что написанная этим кем-то функция может быть закрытой, и залезть к ней внутрь не получается.
VE>Но именно потому и KISS, что исправлять тупой как пробка код проще, чем тот, который перековыривает AST, использует такие фишки языка, о которых дай бог 5-10 спецов в курсе.
Вообще-то, реальный код С# тоже со страшной силой перековыривает AST и использует такие фишки CLR, которые мало кто хорошо знает. И ничего, пользуются, едят.
И отлаживать тупой, как пробка код значительно сложнее, чем умный код. Потому, что умного кода мало, и он понятен. А тупой, как пробка, код отлаживать — мучение. Потому что там 2/3 кода — это мусор, оставшийся от отладки: if с ветками, которые никогда не срабатывают, многократные присваивания одного и того же в результате копи-пейста, и в итоге понять, что на самом деле происходит, крайне тяжело.

VE>Так что хорошим аргументом было бы, если бы реализация макроса lazy была бы проста как пробка; хотя может так оно и есть?
С этим я согласен. Сейчас в форуме немерле идет вялая битва за улучшение возможностей по декомпозиции макросов на более простые кирпичики.

С непривычки и с stl тяжело разобраться. Да и с VCL тоже было весело: ох я наотлаживался в свое время с "заходом внутрь". Но уж потом мы отжигали на Delphi как надо. А индусы как писали на нем же говнокод, так и пишут. И будут писать, хоть с макросами, хоть без.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>Макрос пишется 1 (один) раз на все комы.

Как я понял, в статье говорилось про динамическое обращение к любым методам и свойствам, неважно ком или еще что.

    dynamic
    {
        object myDynamicObject = GetDynamicObject();
        myDynamicObject.SomeMethod();         // call a method   
        myDynamicObject.someString = "value"; // Set a field
        myDynamicObject[0] = 25;              // Access an indexer
    }

[nem-en] Late Binding in Nemerle
Snaury snaury at gmail.com
Sat Jul 1 16:33:42 CEST 2006

Hi everyone,

I was trying to grok nemerle's macros for some time when an idea
suddenly popped in my mind how I could do late binding aka dynamic
typing aka duck typing in a pretty simple and (maybe?) rich way. So I
wrote a macro for this, source code here:
http://www.furry.ru/kitsu/nemerle/Kitsu.LateBindingMacro.n.txt

It allows to use late binding on (I think) any expression, you just
have to wrap it with late, and use like this:

  late(expr).CallMe(param1, param2, param3).CallOtherMe(param, param,
param).Property[param, param, param] = value
...

S>В качестве упражнения попробуй сделать свой динамик, да еще так, чтобы он работал

Да легко:

        public class Dynamic
        {
            private const BindingFlags bindingFlags = BindingFlags.FlattenHierarchy | BindingFlags.Instance | BindingFlags.Public;
            private object obj;
            private string memberName = null;
            public object Value 
            {
                get
                {
                    return memberName == null? obj : GetPropertyValue(obj, memberName, null);
                }
                set
                {
                    SetPropertyValue(obj, memberName, value, null);
                }
            }

            public Dynamic(object obj)
            {
                this.obj = obj;
            }

            public Dynamic this[string propertyName]
            {
                get
                {
                    return new Dynamic(Value) { memberName  = propertyName};
                }
            }

            public Dynamic Call(string methodName, params object[] par)
            {
                object value = Value;
                MethodInfo mInfo = value.GetType().GetMethod(
                    methodName, 
                    (from p in par select p.GetType()).ToArray()
                    );
                if (mInfo == null)
                {
                    throw new ArgumentException("Method " + methodName + " not found");
                }
                return new Dynamic(mInfo.Invoke(value, par));
            }

            private static object GetPropertyValue(object obj, string propertyName, object[] index)
            {
                PropertyInfo propertyInfo = obj.GetType().GetProperty(propertyName);
                if (propertyInfo != null)
                {
                    return propertyInfo.GetValue(obj, index);
                }

                FieldInfo fieldInfo = obj.GetType().GetField(propertyName);
                if (fieldInfo != null)
                {
                    if (index != null && index.Length > 0)
                    {
                        throw new ArgumentException("Field " + propertyName + " can not be accessed by index");
                    }
                    return fieldInfo.GetValue(obj);
                }
                throw new ArgumentException("Property\\field not found: " + propertyName);
            }

            private static void SetPropertyValue(object obj, string propertyName, object propertyValue, object[] index)
            {
                PropertyInfo propertyInfo = obj.GetType().GetProperty(propertyName, bindingFlags);
                if (propertyInfo != null)
                {
                     propertyInfo.SetValue(obj, propertyValue, index);
                     return;
                }

                FieldInfo fieldInfo = obj.GetType().GetField(propertyName, bindingFlags);
                if (fieldInfo != null)
                {
                    if (index != null && index.Length > 0)
                    {
                        throw new ArgumentException("Field " + propertyName + " can not be accessed by index");
                    }

                    fieldInfo.SetValue(obj, propertyValue);
                    return;
                }
                throw new ArgumentException("Property\\field not found: " + propertyName);
            }
        }

        public class TestClass
        {
            public class InternalClass
            {
                public int i = 15;
                public string str = "test string";
                public void SomeMethod(int par)
                {
                    Console.WriteLine("InternalClass::SomeMethod(" + par + ");");
                }
            }
            public int i = 19;
            public InternalClass var = new InternalClass();
        }

        static void Main(string[] args)
        {
            TestClass test = new TestClass();
            object obj = test;
            Dynamic dyn = new Dynamic(obj);
            dyn["var"]["str"].Value = "new test string";
            dyn["var"]["i"].Value = 666;
            dyn["i"].Value = 777;
            dyn["var"].Call("SomeMethod", 888);

            Console.WriteLine("test.var.str = " + test.var.str);
            Console.WriteLine("test.var.i = " + test.var.i);
            Console.WriteLine("test.i = " + test.i);

        }

Было бы желание, а написать все, что угодно можно.

S>Гм. Еще раз поясняю: вот сейчас падает где-то в нативном коде, сгенерированном джитом по мсилу, сгенерированному шарпом по коду, в который
разворачивается синтаксический сахар. И как, тебе это когда-то мешало отлаживать джаву или шарп?

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

S>Любое падение — это падение в нативном коде. Просто потому, что никакого сишарпного кода в момент падения не существует.
Только в случае с макросами непонятно, как можно адекватно проецировать точку падения на код. Ну покажет тебе дебаггер, что при обращении к такому то макросу, где-то произошла ошибка. Дальше что? Это еще не значит, что код, который обращался кривой. Может с кодом все в порядке, а кривой макрос? Или и с кодом, и с макросом все нормально, а кривой энвайронмент?

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

M>>Какая новая технология позволит решить проблему противоречия между краткостью и понятностью кода?
V>Фишка в том, что эта проблема сейчас не стоит перед мейнстримом. Во всяком случае остро. С#-а пока для бизнес-задач хватает — на замену VB6.

Не фишка в том, что блаб-програмисту всегда хватает языка Блаб. Слышал об этой теории?

M>>Скажем, мета-программирование, и Nemerle в частности — решают эту проблему?
V>Лично мне больше нравится выделенный, не смешиваемый с основным кодом DSL, с четко определенными границами и точками соприкосновения с основным кодом.

И сколько ты создал подобных ДСЛ-ей? Можно пример хотя бы одного?

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

V>>Фишка в том, что эта проблема сейчас не стоит перед мейнстримом. Во всяком случае остро. С#-а пока для бизнес-задач хватает — на замену VB6.

VD>Не фишка в том, что блаб-програмисту всегда хватает языка Блаб. Слышал об этой теории?

Слышал. Но я не об этом. Я о том, на ЧТО тратятся усилия программиста (блаб, или супер-мега-гуру-сен-сей-его-святейшества-немерле). Если усилия такого программиста сосредоточены на технической части и от этой части не удается адекватно отгородиться средствами самого языка, то надо улучшать язык. Если программист большую часть времени решает задачи предметной области, то улучшение языка ему побоку. Другими словами, если он мучается поиском ответа на вопрос "КАК ДЕЛАТЬ?", то крутой язык программирования его спасет. Если же его волнует ответ на вопрос "ЧТО ДЕЛАТЬ?", то язык программирования особой роли не играет.

VD>И сколько ты создал подобных ДСЛ-ей? Можно пример хотя бы одного?

Нисколько. Тут речь о поддержке со стороны фреймворка, а может и платформы. Что-то типа прикладного Workflow, чобы оно было понятно бизнес-аналитикам.

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

K>И сколько процентов времени вы отлаживаете сторонний библиотечный код по сравнению с тем, который сами пишете?

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

K>В чем принципиальная разница с любой другой библиотекой?

В том, что отлаживается непосредственно программа, которая падает, а не программа, которая генерирует другую программу, которая падает. Чувствуешь разницу?

K>Вот и prVovik встроил в язык мини динамический DSL. От макроса он отличается тем, что DSL у него не компилируемый, а интерпретируемый — в чем преимущество мне не понятно. Также автор отмечает облегчение при отладке. Это мне тоже не понять. Неужто отлаживать код на DSL вместе с интерпретатором этого DSL каждый раз это удобнее, чем отлаживать сгенерированный код?
K>Где бенефиты-то?

И в чем проявляется компилируемость макроса, если доступ с проверками к свойствам и методам всеравно происходят в рантайме? Соответственно, толку от компайлтайма нет вообще никакого и работают они совершенно одинаково. Разница только маленьком количестве синтаксического сахара.

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

V>Тем не мениее флеймы на эту тему возникали(ют) постоянно, и вовсе не от незнания STL.

От него и только от него. Ну, еще малость от избыточности и кривости STL.

V>Хорошо, возьми вместо STL что-нибудь из Александреску. Компактно? Компактно! Очевидно?

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

V>Ну разве что после поллитры. Хотя ладно, тут опять можно съехать на том, что С++ кривой.

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

V>Давай представим, что настало счастливое будущее. Nemerle покорил мир. Некто Jagadheeswaran получает задание пофиксить баг на web-страничке. Документации, естественно, нет. Людей, которые это писали, конечно, тоже. Открывает он код странички — а там хитросплетение макросов.

Блин, дался тебе этот Немерле. Статья была не о нем. Что вам все время тянет тему сменить?
Ну, да если хочешь обсудить макросы, то давай.

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

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

V>Что тут делается — непонятно, поэтому Jagadheeswaran заглядывает в код макроса. В коде макроса выполяются какие-то мутные операции с AST.

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

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

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

Дестивительно хорошая идея — молчать о том, что сам не пробовал. А то я что-то описанных пугалок не встречал на практике.

ЗЫ

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

V>Вот это и есть неочевидный код.

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

S>>А вот улучшить могут. Потому, что к примеру вместо лапши из вызовов IDispatch на две страницы написан банальный
S>>

lazy Workbook.Sheets[1].Range("A1:A12").Formatting.BackColor=Color.Green;

V>А других вариантов нет? Либо лапша на 2 страницы из вызовов IDispatch, либо макрос?

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

S>>Да, в коде макроса lazy происходят мутнейшие операции с AST. Тем не менее, выполнять их не нужно. Потому что сразу же виден источник ошибки: вставили новый столбец, и надо исправить диапазон на B1:B12.
S>>Вот это и есть очевидный код.

V>Вот незадача, а мы не вставляли новый столбец, а оно всеравно падает

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

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

ЗЫ

Еще раз предлагаю прочесть мою статью, чтобы понять, что я не цепляюсь за идею встроить макросы скажем в C#. Я просто говорю, что развитие компилятора без системы квазицитирования и паттерн-матчинга приводит к дичайшим непродуктивным затратам времени, и что если хотя бы их (т.е. мелкую часть макросов) дать хотя бы группе разработки языков программирования, то это уже ускорило бы "эволюцию" в десятки раз. А если пойти дальше и предоставить людям SDK который позволил бы эксперементировать с языком, то прогресс пошел бы вообще семимильными шагами. Ну, а там уже всем блабам на свете стало бы очевидно, что данную технологию можно дать и простым смертным.

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

V>Гхм. Пардон. lazy — это ленивые вычисления, или что? Если ленивые вычисления, то как они связаны с IDispatch?

Он ошибся. Думаю, имелось в виду late.

V>Наверное, это от того, что у всех разный опыт. Мне несколько раз приходилось занимаься реанимацией проектов, разрабатывавшихся и проваленных индусами. Дак вот, ответственно заявляю: Слава БОГУ, что у этих индусов не было макросов!!!!

Эту фразу можно развернуть против тебя. Если в проекте были бы макросы и при этом его смогли бы написать индусы, то тебя просто бы не пустили реанимировать этот проект, так как во-первых, он и так работал бы не плохо, а во-вторых, ты просто не справился бы с его развитием, так как не имеешь опыта в использовании тех самых макросов.

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

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

S>>В качестве упражнения попробуй сделать свой динамик, да еще так, чтобы он работал

V>Да легко:

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

V>Было бы желание, а написать все, что угодно можно.

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

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

S>>Гм. Еще раз поясняю: вот сейчас падает где-то в нативном коде, сгенерированном джитом по мсилу, сгенерированному шарпом по коду, в который
V>разворачивается синтаксический сахар. И как, тебе это когда-то мешало отлаживать джаву или шарп?

V>У меня ниразу не возникало необходимости отлаживать джаву или шарп.

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

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

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

VE>Но именно потому и KISS, что исправлять тупой как пробка код проще, чем тот, который перековыривает AST, использует такие фишки языка, о которых дай бог 5-10 спецов в курсе.

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

VE>Так что хорошим аргументом было бы, если бы реализация макроса lazy была бы проста как пробка; хотя может так оно и есть?

Ссыкла на код была в статье
http://nemerle.org/svn/nemerle/trunk/macros/Late.n
(если под lazy имелось в виду Late).
Если же интересен именно lazy, то вот его код:
http://nemerle.org/svn/nemerle/trunk/macros/Nemerle.n

  [Nemerle.MacroUsage (Nemerle.MacroPhase.BeforeInheritance,
                       Nemerle.MacroTargets.Parameter)]
  macro Lazy (_ : TypeBuilder, meth : ParsedMethod, parm : ParsedParameter)
  {
    def unique = parm.ParsedName.NewName (Util.tmpname (parm.ParsedName.Id));
    def newBody = Util.locate(meth.Body.Location, 
      <[
        InternalMacros.RedirectName ($(parm.ParsedName : name),
        $(unique : name).Value,
        $(meth.Body))
      ]>);

    meth.Body = newBody;
    parm.name = PT.Splicable.Name (unique);
    //TODO: May be need correct location of parm.ty.
    parm.ty = <[ Nemerle.LazyValue [$(parm.ty)] ]>;
  }
  
  macro lazy (val) {
    match (val) {
      | PT.PExpr.Literal => <[ LazyValue.FromValue ($val) ]>
      | _ => <[ Nemerle.LazyValue (fun () { $val }) ]>
    }
  }

Они и правда прост как пробка.

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

V>>>Но только ты не понял, о чем я писал.

VD>>Сдается мне, что непонимашь тут все же ты.

V>Не понимаю что?

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

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

VD>>Не фишка в том, что блаб-програмисту всегда хватает языка Блаб. Слышал об этой теории?

V>Слышал. Но я не об этом. Я о том, на ЧТО тратятся усилия программиста (блаб, или супер-мега-гуру-сен-сей-его-святейшества-немерле). Если усилия такого программиста сосредоточены на технической части и от этой части не удается адекватно отгородиться средствами самого языка, то надо улучшать язык. Если программист большую часть времени решает задачи предметной области, то улучшение языка ему побоку. Другими словами, если он мучается поиском ответа на вопрос "КАК ДЕЛАТЬ?", то крутой язык программирования его спасет. Если же его волнует ответ на вопрос "ЧТО ДЕЛАТЬ?", то язык программирования особой роли не играет.

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

VD>>И сколько ты создал подобных ДСЛ-ей? Можно пример хотя бы одного?

V>Нисколько.

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

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

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

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

V>И в чем проявляется компилируемость макроса, если доступ с проверками к свойствам и методам всеравно происходят в рантайме? Соответственно, толку от компайлтайма нет вообще никакого и работают они совершенно одинаково. Разница только маленьком количестве синтаксического сахара.

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

prVovik,

V>Фантастика. Фреймворк императивный по своей сути, как и все МС-овские языки под него. Это равнозначно созданию новой другой платформы. МС сейчас на это не пойдет. Я имел ввиду реальный варианнт, а не фантасический.

А, то есть ты ищешь фичу, которую МС в принципе может включить, но не включает из вредности? Боюсь, таких фич нет. Разве что незначительный синтаксический сахар.

LCR>>Ещё примеры — виртуальные классы, структурные типы, макросы, продолжения. (В предположении, что фреймворк джавовский)
LCR>>- Виртуальные классы приводят к тотальному пересмотру всех иерархий классов.

V>Что ты имеешь ввиду под "виртуальным классом"?
Re: Десять вопросов Мартину Одерски о Scala

LCR>>- Структурные типы делают интерфейсы необязательными, статическая типизация сохраняется, но даункасты уже невозможны.

V>А ради чего все это?
Ради выявления как можно большего количества ошибок на этапе компиляции.

LCR>>- Продолжения позволяют реализовать все управляющие конструкции в библиотеке. Сравни веб-фреймворки использующие продолжения, и не использующие их — различия весьма существенны (и для прикладного программиста, и для разработчика фреймворка).

V>В ASP.NET'e и так управляющие конструкции реализованы в библиотеке.

Продолжения позволяют с самого начала получить общее решение с меньшими затратами и наиболее комфортным апи для прикладного программиста: Will Continuations continue?

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

VD>От него и только от него. Ну, еще малость от избыточности и кривости STL.

Ну ОК, не буду спорить. Продолжай думать, что если кто-то с тобой не согласен, то этот кто-то чего-то не знает

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

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

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

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

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

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

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

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

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

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

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

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

VD>Есть. Ждать за заднице 10 лет пока в твой любимый язык не будет встроена нужная тебе сегодня фича.
VD>В результате, сам понимаешь, в коде будет та самая лапша.
Мне потребовалось 15 минут, чтобы сделать набросок динамического хелпера, о котором ты писал в статье.

VD>Только вот вероятность ошибки в макросе в сотни раз ниже вероятности ошибок в прикладном коде.

С чего бы это?

VD>Еще раз предлагаю прочесть мою статью, чтобы понять, что я не цепляюсь за идею встроить макросы скажем в C#. Я просто говорю, что развитие компилятора без системы квазицитирования и паттерн-матчинга приводит к дичайшим непродуктивным затратам времени, и что если хотя бы их (т.е. мелкую часть макросов) дать хотя бы группе разработки языков программирования, то это уже ускорило бы "эволюцию" в десятки раз. А если пойти дальше и предоставить людям SDK который позволил бы эксперементировать с языком, то прогресс пошел бы вообще семимильными шагами. Ну, а там уже всем блабам на свете стало бы очевидно, что данную технологию можно дать и простым смертным.

Боюсь, что твое понимание "прогресса" расходится спониманием МС.

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

VD>Эту фразу можно развернуть против тебя. Если в проекте были бы макросы и при этом его смогли бы написать индусы, то тебя просто бы не пустили реанимировать этот проект, так как во-первых, он и так работал бы не плохо, а во-вторых, ты просто не справился бы с его развитием, так как не имеешь опыта в использовании тех самых макросов.

Вот наивный человек, думает, что сам факт использования макросов автоматически лапшу превращает в гвозди

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

Не вижу логической связи.

VD>И то, что кто-то, в силу однобокости своих знаний не в силах разобраться с этим проектом еще не значит, что проблема в макросах. Ведь проблема в этом ком-то.
Проблема не в невозможности разобраться, а в трудозатратах.

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

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

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

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

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

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

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

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

VD>Это очень правильный вопрос. И не надо смеяться.
VD>Не понимаешь ты, то о чем ведешь речь. Не понимаешь, потому что никогда толком не пробовал, не озабачивался проблематикой. Просто Имешь Мнение которое Хрен Оспоришь.

Ты, наверное, умеешь и диагноз по фотографиям ставить, не так ли?

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

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

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

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

Ага.

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

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

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

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

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

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

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

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

LCR>А, то есть ты ищешь фичу, которую МС в принципе может включить, но не включает из вредности? Боюсь, таких фич нет. Разве что незначительный синтаксический сахар.

Ну дак весь топик посвещен теме "Почему МС не включает ту или иную фичу. Или включает, но медленно". Мой ответ на вопрос: для МС приоритетно прикладное развитие фреймворка, а не отдельно взятого языка.

V>>А ради чего все это?
LCR>Ради выявления как можно большего количества ошибок на этапе компиляции.

И добавления новых?

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

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

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

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

Не сомневаюсь, только он окажется дай бог хотя бы таким же сложным, как макрос; а то и превзойдет его на порядок. Отлаживать его будет не проще.

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

V>Меня не интересует техническая реализация решения — запрограммировать не проблема, это дело техники, прошу прощения за тафталогию. Сложность не в этом.
Это самая очевидная позиция. Лично меня всегда пугает перспектива оказаться в роли "спешного пилильщика тупой пилой". А вдруг мы просто не видим чего-то менее очевидного?
VD>>Простой пример. Ты знаком с XSLT?

V>Замечательно, но только при условии, что программы, написанные на разных языках, не будут смешиваться друг с другом. "Котлеты отдельно, мухи отдельно".
Вот этот момент мне не до конца понятен. По моему опыту, всё как раз наоборот. Я имею примерно 20 лет опыта работы с СУБД; из них примерно 10 — с SQL.
И все эти 10 лет были в том или ином виде посвящены борьбе с границами между языком клиента и языком сервера. Предметная область-то одна! А мне приходится искусственно проводить границы. При этом компилятор клиента ничего не знает про сервер и помочь мне не может, а сервер ничего не знает о клиенте.

И тут появляется Linq, и становится понятно — вот оно! Всё, нет границы между языками манипуляции данными. Я получаю статический контроль всего и поддержку рефакторинга! Что, это плохо? Нет, это именно как оно и должно быть.

Помедитируй над этим примером. Лично у меня есть великое искушение обобщить такой подход и на другие, традиционно изолированные области:
— web client/web server (некоторые шаги в эту сторону делает ASP.NET MVC Framework и мне это очень нравится)
— сборка инсталляторов
— вообще управление сборкой и тестированием проектов

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

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

S>Вот этот момент мне не до конца понятен. По моему опыту, всё как раз наоборот. Я имею примерно 20 лет опыта работы с СУБД; из них примерно 10 — с SQL.
S>И все эти 10 лет были в том или ином виде посвящены борьбе с границами между языком клиента и языком сервера. Предметная область-то одна! А мне приходится искусственно проводить границы. При этом компилятор клиента ничего не знает про сервер и помочь мне не может, а сервер ничего не знает о клиенте.

S>И тут появляется Linq, и становится понятно — вот оно! Всё, нет границы между языками манипуляции данными. Я получаю статический контроль всего и поддержку рефакторинга! Что, это плохо? Нет, это именно как оно и должно быть.

Тут возможны два варианта использования DSL'я
Первый (для меня, наверное, самый важный) — это когда у нас есть некая система сама в себе, и мы выставляем наружу DSL для людей, не являщихся программистами, которые в понятных им терминах предметной области смогут описывать нужное им поведение. Например, бизнес-аналитик на чем-то более человечном и приземленным, нежели BPEL, описывает нужный ему бизнес-процесс и сам же его запускает.

Второй вариант — это DSL для программистов. То есть когда прогаммисты сами для себя придумывают свои собственные новые языки программирования. По-этому, твой пример с Linq vs SQL+XPath не совсем в тему, так как это общеизвестные языки. А что касается дээселей, то тут можно вспомнить пример из жизни. Иногда, люди специально придумывают себе язык. Нпример, бейсболисты. Но у них есть на это существенные основания: 1) не надрывать горло; 2)держать план в тайне от соперников. Но в повседневной жизни люди обычно не придумывают новые языки, так как это усложняет общение. Я не говорю, что макросы и метопрограммирование бесполезны. Я хочу сказать, что их значимость для прикладных программистов сильно переоценена некоторыми посетителями этого форума и именно по-этому они не понимают действия Майкрософта.

S>Помедитируй над этим примером. Лично у меня есть великое искушение обобщить такой подход и на другие, традиционно изолированные области:
S>- web client/web server (некоторые шаги в эту сторону делает ASP.NET MVC Framework и мне это очень нравится)
S>- сборка инсталляторов
S>- вообще управление сборкой и тестированием проектов
Хм.. Какой подход обобщить? Что ты имеешь ввиду?

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

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

VE>Не сомневаюсь, только он окажется дай бог хотя бы таким же сложным, как макрос; а то и превзойдет его на порядок. Отлаживать его будет не проще.

Согласен, но дело не в этом. Выше утверждалось, что для программиста существуют только три варианта: 1) копипастить макароны; 2) использовать метопрограммирование; 3) ждать, пока МС реализует dynamic в компиляторе. Я показал, что это неверно.

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

S> При этом все их действия показывают, что именно встроенные в язык DSL считаются правильным медом(ТМ).

Ну, это ты загнул. Есть ведь, к примеру, DSL Tools, есть всякие .dbml, .edml. Microsoft выбирает то, что в каждом конкретном случае оптимально.

... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>

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

AVK>Ну, это ты загнул. Есть ведь, к примеру, DSL Tools, есть всякие .dbml, .edml. Microsoft выбирает то, что в каждом конкретном случае оптимально.
Согласен. Видно, что далеко не все DSL они готовы приветствовать в шарпе

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

V>> Я показал, что это неверно.
S>Ты всего лишь показал, что на turing-complete языке запрограммировать можно всё, что угодно.

А к чему тогда было заявление, что единственный оставшийся вариант — это копипаст лапша-кода?

S>С тем же успехом можно было обобщить твои рассуждения на, скажем, генерик-типы.
S>Я бы говорил, что программиста есть ровно три варианта, а ты бы говорил, что List object'ов вполне приемлемый результат.

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

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

K>>В чем принципиальная разница с любой другой библиотекой?
V>В том, что отлаживается непосредственно программа, которая падает, а не программа, которая генерирует другую программу, которая падает. Чувствуешь разницу?

Если есть compile-time кодогенератор, можно отлаживать и кодогенератор и сгенерированный код отдельно. В случае с интерпретатором, который вы продемонстрировали, отлаживать код на EDSL можно только вместе c интерпретатором EDSL.
Вместо программы, которая генерирует другую программу, вы имеете программу, которая интерпретирует другую программу, какие недостатки есть в первом случае, а во втором отсутствуют?
Что касается разницы с любой другой библиотекой — в одном случае вы можете получить неправильные данные из сторонней библиотеки, в другом случае — неправильный код. Разница есть только в том случае, если считать, что есть разница между кодом и данными — а это вопрос дискуссионный, если не просто технический, касающийся реализации. Если уж на то пошло, в управляемый средах код и так уже является данными, но только в рантайме, а не в компайлтайме.

K>>Вот и prVovik встроил в язык мини динамический DSL. От макроса он отличается тем, что DSL у него не компилируемый, а интерпретируемый — в чем преимущество мне не понятно. Также автор отмечает облегчение при отладке. Это мне тоже не понять. Неужто отлаживать код на DSL вместе с интерпретатором этого DSL каждый раз это удобнее, чем отлаживать сгенерированный код?
K>>Где бенефиты-то?
V>И в чем проявляется компилируемость макроса, если доступ с проверками к свойствам и методам всеравно происходят в рантайме?

Мы начали с того, что вы утверждали, что ваш EDSL интерпретатор лучше, чем компилятор, а теперь уже приходим к тому, что нет разницы? Вообще, разница есть даже в этом случае, который и так динамический и разница, конечно, не велика.

V>Соответственно, толку от компайлтайма нет вообще никакого и работают они совершенно одинаково. Разница только маленьком количестве синтаксического сахара.

Т.е. ваше отношение к синтаксису зависит от того, насколько оно поддерживает вашу точку зрения? Так дело не пойдет.

Разница, как минимум, в двух вещах.
1) Вы не можете отлаживать код на своем EDSL не отлаживая при этом интерпретатор, а зачем программисту, использующему EDSL копаться во внутренностях интерпретатора мне не понятно.
2) Ваш EDSL интерпретатор вводит новый синтаксис вызова методов — макрос оставляет синтаксис неизменным.

Т.е. вы предъявляли претензии к отладке и к синтаксису, но в обоих случаях ваше же решение и проигрывает.

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

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

K>Если есть compile-time кодогенератор, можно отлаживать и кодогенератор и сгенерированный код отдельно. В случае с интерпретатором, который вы продемонстрировали, отлаживать код на EDSL можно только вместе c интерпретатором EDSL.
Ну да, нажать "Step Over" — это очень трудно.

K>Вместо программы, которая генерирует другую программу, вы имеете программу, которая интерпретирует другую программу, какие недостатки есть в первом случае, а во втором отсутствуют?

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

K>Мы начали с того, что вы утверждали, что ваш EDSL интерпретатор лучше, чем компилятор, а теперь уже приходим к тому, что нет разницы? Вообще, разница есть даже в этом случае, который и так динамический и разница, конечно, не велика.

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

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

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

В общем случае — нет. Но есть такие физиономии по которым диагноз виден невооруженным взглядом.

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V>Ага.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если быть точным, то с 12.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, 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>значит пример просто выбран не корректно

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто угодно (даже VladD2!!!), не понимающий в коде, оценит самый выразительный и лаконичный код как совершенно запутанный и непонятный.

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

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

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

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

С одной стороны, да, ты говоришь резонно. Обоснованная потребность в отдельных встроенных DSL'ях возникает очень редко и круг задач весьма ограничен. МС предпочитает делать специализированное решения, которые имеют важное преимущество: они стандартны и well-known. Соответственно, для проекта just-for-fun я бы выбрал lisp-подход, когда по сути мы сначала для себя делаем некий уникальный и идеально подходящий нам DSL, а потом на этом DSL'e воротим горы. Но вот для промышленного проекта, который разрабатывается кучей народа и который должен пережить несколько поколений разрабатывающих/поддерживающих его команд, я выберу подход МС. Это надежнее.

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

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

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

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

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

Не то чтобы я спорил бы. Но мне кажется, Шарп в принципе и не должен развиваться по другому. Сила .NET как раз в том, что он изначально многоязычный by design, что позволяет выполнить "диверсификацию", удовлетворяя разными языками потребности разных групп пользователей. Ориентацией на многоязычность МС сильно развязал себе руки. Хотите более радикальный и инновационный подход — берите F#. C# — ориентирован на более консервативную аудиторию, он позиционируется как самый мэйнстримовый язык MS-а, нет? Однако, удивительное рядом. Я не силен в третьем шарпе, но судя по тем отголоскам и слухам, что до меня доходят — в его развитии Майкрософт зашел несколько дальше, активно заимствуя новые концепции, чем добавление простых клуджей-одноходовок под нужды библиотек.

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

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

.

Я знаю ЧТО? Что это крутой мужик, с извесной фирмой? Это хоть как-то отменяет тот факт, что его hype методика базируется на последствиях, а не причинах? Чем отличаются последствия от причин я тебе уже писал.

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

G>Ну откуда тебе знать, чем лучше пользоваться, если ты от маркетинга далек до такой степени, как Аристотель до луны?

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

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

Самому не смешно? Тебе еще аргументы какие-нибудь нужны? Осень наступила чтоли, не пойму?

Ты мне хоть один аргумент приведи, кроме крутизны и бездонности знаний тов.Гартнера.
Возьми его методику на вооружение и выведи из неё — куда будет идти прогресс, какие идеи так и останутся без надобности, а какие будут востребованы. Скажи когда нужна будет та или иная технология (ведь нужно прийти с ней "вовремя", не так-ли?).
Главное — что hype методика может ПРЕДСКАЗАТЬ, а не "объяснить" ПОСТФАКТУМ.
Вот прям по пунктам, которые ты описал —
а) эволюционность и революционность технологии, как их разделить, как определить сроки требуемые для революционных технологий, почему одни выстрелили (вроде C/Unix), а другие нет (вроде Lisp/FP), и если выстреля — то когда.
б) методику разделения технологий на меняющие жизнь и нет, почему ты решил, что Nemerle не меняет жизнь, какие из IT технологий поменяют нашу жизнь и т.п.
в) как пресказать — вовремя вошла технология или нет, почему пришедшая раньше срока технология умирает (вместо чтоб возродиться когда прийдёт ей время) и т.п.

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

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

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

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

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

А я и не приводил это, как аргумент в общем споре.

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

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

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

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

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

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

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

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

В том и проблема языков программирования, которые не поддерживают мета-программирование. Если вы вносите новую фичу — она там останется до конца дней, и надо будет переписывать все существующие средства программирования, и потом уже исправить будет нельзя, и сделать её надо так, чтоб она по возможности подошла всем. А получается — всем кое-как подходит, но никому не подходит в точности.
В том-то и дело, что при мета-программировании всю эту тучу проблем решать не нужно. Мы вводим новое семантическое понятие для данного проекта, мы его потом можем изменить, оно идеально подходит именно к этому проекту. И добавить его — 5 минут работы. И будет работать оно через 5 минут, а не через 3 года.

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

G>Не то чтобы я спорил бы. Но мне кажется, Шарп в принципе и не должен развиваться по другому. Сила .NET как раз в том, что он изначально многоязычный by design, что позволяет выполнить "диверсификацию", удовлетворяя разными языками потребности разных групп пользователей. Ориентацией на многоязычность МС сильно развязал себе руки. Хотите более радикальный и инновационный подход — берите F#. C# — ориентирован на более консервативную аудиторию, он позиционируется как самый мэйнстримовый язык MS-а, нет? Однако, удивительное рядом. Я не силен в третьем шарпе, но судя по тем отголоскам и слухам, что до меня доходят — в его развитии Майкрософт зашел несколько дальше, активно заимствуя новые концепции, чем добавление простых клуджей-одноходовок под нужды библиотек.

В третьем шарпе все изменения делятся на две группы: те, что вводились для поддержки Linq, и те, что вводились для упрощения автоматической кодогенерации. Пусть меня поправят, если я что-то упустил.

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

AVK>Т.е. гнобить на основании того, что человек якобы религиозный фанатик, можно?
нет конечно, но он являлся гражданином своей страны, и если закон этой страны требует от него платить налоги и не иметь дел со странами на которое оно (государство) наложили свое эмбарго,а Фишер осознанно это сделал, то стоит ли удивляться, что его стали гнобить?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>Толку тебе приводить пример из собственного опыта, если ты не представляешь всей сложности проблемы, решённой макросом.
M>Любой достаточно сложный проект можно привести в пример. Ты со сложными проектами работал? С какими, приведи пример, и получишь понятный тебе ответ.

CRM, Sales front-office, "Молотилки данных", системы, автоматизирующие всевозможные бизнес-процессы, интеграция чего угодно с чем угодно.

M>Так мета-программирование одним nemerle не исчерпывается.

Под метопрограммированием в данном случае я понимал прежде всего макросы. Согласен, это слишком узко.

M>И рефакторинг в средах с мета-программированием работает даже лучше, чем в обычных языках.
M>Скажем, тебе надо заменить операцию сгенерированным кодом, в котором нужны временные переменные.
M>В простом языке программирования тебе надо исхитрится и продекларировать эту временную переменную
M>в том месте, где можно, и имя ей придумать такое, чтоб не перекрывало имеющиеся имена.
M>И всё равно это не покроет все возможные варианты. Например, в java в конструкторе ты пишешь

M>

M>class Foo {
M>  Foo(int i) {
M>    super(i);
M>  }
M>}
M>

M>тебе надо заменить i на некоторый код, который требует временной переменной. А ты эту временную
M>переменную никуда вписать не сможешь, потому как super() вызов конструктора должен быть _первым_,
M>никакие декларации переменных и вообще ничего до него быть не может.
M>Никакой рефакторинг тебе не поможет. И кодо-генерация исходников не поможет — нельзя написать
M>валидный код.

Я уже плохо помню яву, но разве так нельзя:

class Foo {
  Foo(int i) {
    super(Initialize(i));
  }
  int Initialize(int i)
  {
    ...
  }
}
M>

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

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

G>>Не то чтобы я спорил бы. Но мне кажется, Шарп в принципе и не должен развиваться по другому. Сила .NET как раз в том, что он изначально многоязычный by design, что позволяет выполнить "диверсификацию", удовлетворяя разными языками потребности разных групп пользователей. Ориентацией на многоязычность МС сильно развязал себе руки. Хотите более радикальный и инновационный подход — берите F#. C# — ориентирован на более консервативную аудиторию, он позиционируется как самый мэйнстримовый язык MS-а, нет? Однако, удивительное рядом. Я не силен в третьем шарпе, но судя по тем отголоскам и слухам, что до меня доходят — в его развитии Майкрософт зашел несколько дальше, активно заимствуя новые концепции, чем добавление простых клуджей-одноходовок под нужды библиотек.

V>В третьем шарпе все изменения делятся на две группы: те, что вводились для поддержки Linq, и те, что вводились для упрощения автоматической кодогенерации. Пусть меня поправят, если я что-то упустил.

http://en.wikipedia.org/wiki/C_Sharp_(programming_language)#Features_of_C.23_3.0

Features of C# 3.0

C# 3.0 is the current version, and was released on 19 November 2007 as part of .NET Framework 3.5. It includes new features inspired by functional programming languages such as Haskell and ML, and is driven largely by the introduction of the Language Integrated Query (LINQ) pattern to the Common Language Runtime.[10]

Linq
Language Integrated Query:[11] "from, where, select" context-sensitive keywords allowing queries across SQL, XML, collections, and more. These are treated as keywords in the LINQ context, but their addition won't break existing variables named from, where, or select.

Object initializers
Customer c = new Customer(); c.Name = "James";
can be written
Customer c = new Customer { Name="James" };

Collection initializers
MyList list = new MyList(); list.Add(1); list.Add(2); can be written as MyList list = new MyList { 1, 2 }; (assuming that MyList implements System.Collections.IEnumerable and has a public Add method[12])

Anonymous types
var x = new { Name = "James" }

Local variable type inference
Local variable type inference: var x = "hello"; is interchangeable with string x = "hello";. More than just syntactic sugar, this feature is required for the declaration of anonymous typed variables.

Lambda expressions
Lambda expressions: listOfFoo.Where(delegate(Foo x) { return x.Size > 10; }) can be written listOfFoo.Where(x => x.Size > 10);
Compiler-inferred translation of Lambda expressions to either strongly-typed function delegates or strongly-typed expression trees.

Automatic properties
The compiler will automatically generate a private instance variable and the appropriate getter and setter given code such as: public string Name { get; private set; }

Extension methods
Extension methods (adding methods to classes by including the this keyword in the first parameter of a method on another static class)

Partial methods
Allow codegenerators to generate method declarations as extension points that are only included in the source code compilation if someone actually implements it in another portion of a partial class.[13]

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

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

S>Если быть точным, то с 12.

У каждого в детстве были свои soft toys

Неясность изложения обычно происходит от путаницы в мыслях.

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

G>Ну хорошо, давай поговорим. Опустим то, что ты мне писал об отличиях причин отследствий (я, как человек с высшим математическим образованием, в курсе этой тонкой разницы), и остановимся для начала на том, в чем ты делаешь ошибку с самого начала. Ты не прав в том, что она базируется на последствиях. Хайп — является не только следствием, но и причиной, это необходимый и важный элемент процесса внедрения инноваций. Допустим, я придумал крутую штуку. Если я о ней не пишу, и она не вызывает бурного обсуждения в публикациях, как ты (а главное — широкая общественность, и инвесторы) о ней узнают? С другой стороны — если я пишу, а хайпа нет — это означает ровно одно. Людям это не интересно, и это не затрагивает никаких значимых потребностей.

Так я же сразу сказал — hype это элемент социодинамики вокруг технологии. Конечно, какая-то социодинамика вокруг технологии всегда будет, и её можно померять, тем-же количеством публикаций и пр. Но она вторична, это величина измеряемая, а не причинная. Да, известность технологии, hype, buzzword — определяет количество вкладываемых денег на определённом этапе развития технологии. Но не она определяет — будет технология развиваться или помрёт, и если будет развиваться — то куда и как.
Ты хочешь вложить деньги в новую технологию и получить прибыль. На каком этапе ты это должен делать? Ясно, что не на вершине hype-а. В это время все вкладывают деньги, и через некоторое время теряют их. Банальный эффект толпы — все ломанулись, и попередавили друг друга.
Вкладывать можно когда технология прошла минимум и опять начала развиваться — но там уже ты получишь стандартную норму прибыли, и тебе надо вложить очень много если ты хочешь войти как новый игрок на рынок. И не факт, что ты получишь даже эту стандартную норму прибыли — технология может не пойти вверх достаточно быстро и сильно. Так и помрёт.

Простой пример с dynamic языками (Perl, Python, PHP, Ruby). Мы имели кучу хайпа в недавнее время (по видимости, они как раз прошли первый пик). Что с ними будет дальше? Как высоко они пойдут в подъём после прохождения минимума, и пойдут ли вообще, и если пойдут — то в каком направлении будет развиваться технология (от этого зависит — во что именно вкладывать средства)? Почему они выстрелили именно сейчас, а не раньше или позже — ведь они давно существуют!
Если рассматривать явление dynamic языков с эволюционной точки зрения — то ответы ясно видны. Я уже писал об этом выше. Вкратце — модель их выхода в mainstream аналогична модели вытеснения лесов степью. Как трава на самом первом этапе роста лучше деревьев, так и динамические языки лучше строгих на этапе начала проекта. Они позволяют быстрее и удобней написать работающий код. Вот только они не могут соревноваться со строгими языками при дальнейшем росте размера программы. Слишком неэффективны (в смысле ресурсов — скорости и памяти), слишком тяжело отладить (компилятор не может контролировать ошибки) и пр.
В среде программ-однодневок динамические языки чуствуют себя прекрасно. Вот PHP и Ruby поднялись на волне массового спроса на сайты-однодневки.
Если дальнейшее развитие IT предоставит среду для динамических языков (программы-однодневки) — они будут развиваться и после минимума на кривой hype-а будет опять рост. А если не будет этой среды — не будет подъёма после минимума. Просто не будет.
Если вкладывать в них деньги — очевидно, надо их вкладывать в ту технологию, которая позволит переход от динамики к строгому языку при росте проекта, сохранив простоту на начальном этапе создания программы. Такая технология в конце концов вытеснит старые строгие языки программирования, за счёт того, что начинать проекты будут на ней, и главное — продолжать их будут тоже на ней, а не переписывать всё с нуля.
И это никакого отношения к маркетингу и хайпу не имеет. Независимо от количества вложенных средств и рекламы — развитие будет идти по этим законам, а не по желанию маркетологов.

G>Кривая хайпа всегда примерно одинакова, это закономерность, которая соблюдается в большинстве случаев, и предсказывать ее форму каждый раз не надо. Надо делать две вещи.
G>1) Определять место технологии на кривой в данный момент, что сделать вполне можно.
G>2) Прогнозировать скорость ее движения по кривой.

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

G>Сама кривая хайпа имеет исключительно иллюстративные цели, не являясь мега-методикой, из которой аналитики компании Гартнер делают свои выводы, и серебряной пулей. Она в наглядной форме постоянно напоминает об этой закономерности.

Хорошо, в качестве иллюстративной методики у меня к ней претензий нет.
Но почему ты тогда советуешь Владу ориентироваться на эту кривую, которая просто иллюстрирует, а не объясняет (в том числе, и "почему развитие идёт именно так")?

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

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

Т.е. ты сознательно привел не относящуюся к делу информацию в качестве аргумента.

C>, но он являлся гражданином своей страны, и если закон этой страны требует от него платить налоги и не иметь дел со странами на которое оно (государство) наложили свое эмбарго,а Фишер осознанно это сделал, то стоит ли удивляться, что его стали гнобить?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

M>>Толку тебе приводить пример из собственного опыта, если ты не представляешь всей сложности проблемы, решённой макросом.
M>>Любой достаточно сложный проект можно привести в пример. Ты со сложными проектами работал? С какими, приведи пример, и получишь понятный тебе ответ.

V>CRM, Sales front-office, "Молотилки данных", системы, автоматизирующие всевозможные бизнес-процессы, интеграция чего угодно с чем угодно.

Хм. Фатальное несовпадение областей работы. Ни с чем из вышеприведённого не работал, конкретно привести пример не могу.

V>Я уже плохо помню яву, но разве так нельзя:
V>

V>class Foo {
V>  Foo(int i) {
V>    super(Initialize(i));
V>  }
V>  int Initialize(int i)
V>  {
V>    ...
V>  }
V>}
M>>

Тут ты меня поймал.

Можно, конечно, если Initialize будет static.
Так кодогенераторы и мучаются. Нельзя же заводить отдельный метод на каждую переписываемую операцию (а если заводить — то за лесом деревья не увидишь). Вот они в одно месте делают так, в другом эдак. В результате сложность генератора текста возрастает на порядок. Потом хрен разберёшся, чего они нагенерировали, а не разобравшись — хрен отладишь. Это я по опыту работы с генераторами парсеров говорю.

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

V>В третьем шарпе все изменения делятся на две группы: те, что вводились для поддержки Linq, и те, что вводились для упрощения автоматической кодогенерации.

Информация из первых рук — функциональные фичи в 3 шарпе специально делались максимально универсальными, а не потому что так получилось при реализации linq.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

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

V>>В третьем шарпе все изменения делятся на две группы: те, что вводились для поддержки Linq, и те, что вводились для упрощения автоматической кодогенерации.

AVK>Информация из первых рук — функциональные фичи в 3 шарпе специально делались максимально универсальными, а не потому что так получилось при реализации linq.

Возможно. Но сам список фич явно определялся потребностями Linq.

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

V>>В третьем шарпе все изменения делятся на две группы: те, что вводились для поддержки Linq, и те, что вводились для упрощения автоматической кодогенерации.

AVK>Информация из первых рук — функциональные фичи в 3 шарпе специально делались максимально универсальными, а не потому что так получилось при реализации linq.

Но если бы не линк, то они вообще бы не далались. Разве не так?

Неясность изложения обычно происходит от путаницы в мыслях.

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

V>Возможно. Но сам список фич явно определялся потребностями Linq.

Тоже далеко не факт. LINQ можно было реализовать и по другому, C омега тому примером.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

G>Питон с Руби и PHP, кстати, которые ты помянул, давно уже в мэйнстриме, и свою нишу заняли. Это зрелые технологии, как и Java. А "динамические языки" просто нельзя наносить как точку на хайп, это не является сомостоятельной технологией, это собирательный термин.

Пардон, здесь я объективно ошибся. Ruby, судя по публикациям, сейчас как раз в самую "яму" угодил. А Питон — чуть дальше, на выходе из ямы.

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

G>>Питон с Руби и PHP, кстати, которые ты помянул, давно уже в мэйнстриме, и свою нишу заняли. Это зрелые технологии, как и Java. А "динамические языки" просто нельзя наносить как точку на хайп, это не является сомостоятельной технологией, это собирательный термин.

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

Так он же всего год-два назад был на самой вершине.
Он точно из ямы выберется?

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

M>>В том-то и дело, что при мета-программировании всю эту тучу проблем решать не нужно.

AVK>В свое время никто так и не ответил — кто будет дорабатывать под очередной макрос ReSharper. Все что удалось получить — дескать, Nemerle настолько крут, что решарпер ему нафик не нужен.

Очевидно, дорабатывать его надо тем, кто его хочет использовать.
Раз не дорабатывают — значит не нужен. То есть средства затраченные на его доработку не окупятся при применении доработанной версии.
Тут либо доработка сложна, либо бенефит получится незначительный.

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

IT>Да тут и гадать нечего. Достаточно здарого смысла, чтобы понять, что функциональные фишки в C# — это побочный эффект добавления Linq.

Не факт. Погляди на си омегу — там ведь совсем по другому было. Что точно можно приписать линку — это expression tree и отчасти анонимные типы. Все остальное вполне себе самоценно, и выискивать, что там было курицей, а что яйцом — бесперспективное, а, главное, бесполезное занятие.

IT> С другой, надеяться на добавление новых стоит только, если они будут частью чего-то большего.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

IT>>Да тут и гадать нечего. Достаточно здарого смысла, чтобы понять, что функциональные фишки в C# — это побочный эффект добавления Linq.

AVK>Не факт. Погляди на си омегу — там ведь совсем по другому было. Что точно можно приписать линку — это expression tree и отчасти анонимные типы. Все остальное вполне себе самоценно,

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

AVK>и выискивать, что там было курицей, а что яйцом — бесперспективное, а, главное, бесполезное занятие.

Занятие более чем полезное, т.к. позволяет понять направление мыслей разработчиков.

IT>> С другой, надеяться на добавление новых стоит только, если они будут частью чего-то большего.

AVK>Не совсем так. По слухам, много чего планируется исключительно благодаря community feedback.

Интересно было бы взглянуть на списочек хоть краем глаза. Хоть на край списочка

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

Будут трясти существующую или писать новую?

Неясность изложения обычно происходит от путаницы в мыслях.

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

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

Ну, как минимум, учитывая что query comprehension напрямую синтаксис лямбд не использует, без лямбд можно было бы и обойтись

. А вообще — все это бесполезные рассуждения, толку от них 0. Что точно известно — сиомега (а был еще какой то гибрид джавы с sql) показывает, что все могло быть сделано и без функциональщины. А сделали с ней. И уж что там было важнее — дело темное.

IT>Занятие более чем полезное, т.к. позволяет понять направление мыслей разработчиков.

Это вряд ли. Там столько могло учитываться моментов, о которых мы никогда не узнаем, что все это сродни гаданию на кофейной гуще.

AVK>>Не совсем так. По слухам, много чего планируется исключительно благодаря community feedback.

IT>Интересно было бы взглянуть на списочек хоть краем глаза. Хоть на край списочка

У меня его нету. Полгода назад для 4 шарпа было: ковариантность дженериков, extension everything и динамика. По поводу второго Кирилл писал что все, зарубили (как раз фича, которую хотело комьюнити), а третье вообще странная идея. Так что что в итоге выродится фик его знает.

IT>Будут трясти существующую или писать новую?

Трясти существующую. Проект новой студии ака Наутилус похоронен окончательно. Но кое какие куски из него будут в новой студии.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

AVK>>>Не совсем так. По слухам, много чего планируется исключительно благодаря community feedback.

IT>>Интересно было бы взглянуть на списочек хоть краем глаза. Хоть на край списочка

AVK>У меня его нету. Полгода назад для 4 шарпа было: ковариантность дженериков, extension everything и динамика. По поводу второго Кирилл писал что все, зарубили (как раз фича, которую хотело комьюнити), а третье вообще странная идея. Так что что в итоге выродится фик его знает.

Была одна фича от комьюнити (напланировали конечно много) и ту зарубили

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

Неясность изложения обычно происходит от путаницы в мыслях.

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

IT>Была одна фича от комьюнити (напланировали конечно много) и ту зарубили

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

AVK>Т.е. ты сознательно привел не относящуюся к делу информацию в качестве аргумента.
фраза про религиозного фанатика относилась к тому, что Фишер не является хорошим, да и вообще примером борьбы гражданина США против политики государства. Так же как и наши "закопанцы" ждавшие конца света.

AVK>А это уже не важно. Я просто привел пример того, что станет с человеком, который попробует переть против политики государства.
важно, в данном случае он нарушал его законы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

M>>Очевидно, дорабатывать его надо тем, кто его хочет использовать.
AVK>Все, не продано.

А что, кто-то покупал? Ты готов заплатить денег разработчикам Nemerle?

M>>Тут либо доработка сложна, либо бенефит получится незначительный.

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

Какие проекты — такие и инструменты. Если твоим проектам с головой хватает продуктов JetBrains — то и покупай у них. Это будет правильно.
А если тебе их не хватает? Когда твой проект вырастет на десяток мегабайт исходников — перестанет хватать.
Будет намного дешевле написать "плагин", который твой десяток мегабайт превратит в три-четыре, и над проектом можно будет работать
дальше. Вместо чтоб нанять ещё сотню программистов, и завести проект в совсем убитое состояние.
Вот тут проблема Nemerle и вылазит. Нельзя перейти на Nemerle, когда перестаёт хватать C#.
Но это проблема Nemerle как такового, а не принципиально нерешаемая проблема.
Скажем, SymADE проектируется так, что эта проблема в нём будет решена.
Или за счёт чего так поднялся AOP? Его можно начать использовать в любой момент. Пусть он не настолько наворочен, как Nemerle, но он совместим с уже имеющимся кодом.

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

G>Прочитал твой ответ целиком. Кажется, я понял твою проблему. Тебе не Гартнер нужен. Тебе нужно вот это. Я начал месяц назад это переводить, думая опубликовать перевод, но не закончил. Ты по английски читаешь? Короче, даю как есть. 17 самых распространенных ошибок стартапщиков от профессионального успешного стартапщика.

Спасибо, я читал этот текст.
Понятно, что ответить мне на него особенно нечего. То есть я могу долго рассказывать, почему мои оценки правильные.
Но это будет выглядеть как профессор физики, рассказывающий почему его теория правильная — увы, инвестор
всё равно не поймёт, поскольку физики и математики в этом объёме он не знает. И разумеется, профессор не сможет
определить правильные объёмы инвестирования и стратегию сбыта — он в этом так-же мало смыслит, как
инвестор в физике.
Так они и жили.

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

M>Какие проекты — такие и инструменты. Если твоим проектам с головой хватает продуктов JetBrains — то и покупай у них. Это будет правильно.
M>А если тебе их не хватает? Когда твой проект вырастет на десяток мегабайт исходников — перестанет хватать.
M>Будет намного дешевле написать "плагин", который твой десяток мегабайт превратит в три-четыре, и над проектом можно будет работать
M>дальше. Вместо чтоб нанять ещё сотню программистов, и завести проект в совсем убитое состояние.
M>Вот тут проблема Nemerle и вылазит. Нельзя перейти на Nemerle, когда перестаёт хватать C#.

а можно пример перехода с десятков мегабайт на вообще что-то другое? обычно у менеджмента одна только мысль о подобном святотатстве(ну как — мы же 5ть лет фигачили, вложили миллионы итд итп) вызывает бурные всплески гнева.

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

D>а можно пример перехода с десятков мегабайт на вообще что-то другое? обычно у менеджмента одна только мысль о подобном святотатстве(ну как — мы же 5ть лет фигачили, вложили миллионы итд итп) вызывает бурные всплески гнева.

Скажем, у меня в компиляторе поддерживается версионное AST дерево. Для этого все обращения к полям AST узлов заменяются на getter/setter-ы, которые генерируются автоматически, или переписываются объявленные явно. Кроме того, генерируется мета-информация доступная в рантайм для полей аттрибутов/child узлов AST узлов. Это позволяет обходить дерево не используя вручную написанных visitor-ов и многое другое.
Вот такой код (я специально беру пример попроще, а то большой фиг разберемся)

@ThisIsANode
public class Binding extends ENode {
    @nodeAttr public UIEvent∅ events;
    
    @SymbolRefAutoComplete @SymbolRefAutoResolve
    @nodeAttr
    public final Action⇑ action;

    public String toString() { return "bind action: "+action+" to {"+Arrays.toString(events)+")"; }

}

Превращается в

public class Binding extends ENode
{
    static final class NodeAttr_events extends SpaceAttAttrSlot
    {

        public final ANode[] getArray(ANode parent)
        {
            return ((Binding)parent).getEvents();
        }

        public final void setArray(ANode parent, Object narr)
        {
            ((Binding)parent).setEvents((UIEvent[])narr);
        }

        NodeAttr_events(String name, TypeInfo typeinfo)
        {
            super(name, typeinfo);
        }
    }

    static final class NodeAttr_action extends AttAttrSlot
    {

        public final Object get(ANode parent)
        {
            return ((Binding)parent).getAction();
        }

        public final void set(ANode parent, Object val)
        {
            throw new RuntimeException("@nodeAttr action is not writeable");
        }

        public final boolean isWrittable()
        {
            return false;
        }

        NodeAttr_action(String name, TypeInfo typeinfo)
        {
            super(name, typeinfo);
        }
    }

    public static class VVV extends kiev.vlang.ENode.VVV
    {

        UIEvent events[];

        public VVV(Binding node)
        {
            super(node);
            events = node.events;
        }
    }


    public String toString()
    {
        return (new StringBuilder()).append("bind action: ").append(getAction()).append(" to {").append(Arrays.toString(getEvents())).append(")").toString();
    }

    public Binding()
    {
        setEvents((UIEvent[])((AttrSlot) (nodeattr$events)).defaultValue);
        action = new SymbolRef($typeinfo$1);
        if(getAction() != null)
            getAction().callbackAttached(this, nodeattr$action);
    }

    public final void setEvents(UIEvent value[])
    {
        if(ASTNode.EXECUTE_UNVERSIONED || !isVersioned())
            events = value;
        else
        if(Thread.currentThread().getThreadGroup() == CompilerThreadGroup.$instance)
            ((Binding)ASTNode.openCmp(this)).events = value;
        else
            ((VVV)ASTNode.openEdt(this)).events = value;
    }

    public final UIEvent[] getEvents()
    {
        return !ASTNode.EXECUTE_UNVERSIONED && Thread.currentThread().getThreadGroup() != CompilerThreadGroup.$instance && super.v_editor != null ? ((VVV)super.v_editor).events : events;
    }

    public final SymbolRef getAction()
    {
        return action;
    }

    public AttrSlot[] values()
    {
        return $values;
    }

    public Language getCompilerLang()
    {
        return (Language)null;
    }

    public String getCompilerNodeName()
    {
        return "Binding";
    }

    public Object copyTo(Object to$node, kiev.vtree.ANode.CopyContext in$context)
    {
        Binding node = (Binding)super.copyTo(to$node, in$context);
        nodeattr$events.copyFrom(node, getEvents(), in$context);
        getAction().copyTo(node.getAction(), in$context);
        return node;
    }

    protected void walkTreeFastVisit(TreeWalker $walker)
    {
        $walker.visitANodeSpace(getEvents());
        $walker.visitANode(getAction());
        super.walkTreeFastVisit($walker);
    }

    public void nodeRestore(kiev.vtree.ASTNode.VVV from)
    {
        VVV from = (VVV)from;
        events = from.events;
        super.nodeRestore(from);
    }

    public kiev.vtree.ASTNode.VVV nodeBackup()
    {
        return new VVV((Binding)this);
    }

    UIEvent events[];
    final SymbolRef action;
    public static final NodeAttr_events nodeattr$events;
    public static final NodeAttr_action nodeattr$action;
    private static final AttrSlot $values[];
    static final TypeInfo $typeinfo$0;
    static final kiev.vlang.SymbolRef.__ti__ $typeinfo$1;

    static 
    {
        $typeinfo$0 = TypeInfo.newTypeInfo(kiev/fmt/evt/Action, null);
        $typeinfo$1 = kiev.vlang.SymbolRef.__ti__.newTypeInfo(kiev/vlang/SymbolRef, new TypeInfo[] {
            $typeinfo$0
        });
        nodeattr$events = new NodeAttr_events("events", TypeInfo.newTypeInfo(kiev/fmt/evt/UIEvent, null));
        nodeattr$action = new NodeAttr_action("action", kiev.vlang.SymbolRef.__ti__.newTypeInfo(kiev/vlang/SymbolRef, new TypeInfo[] {
            $typeinfo$0
        }));
        $values = (new AttrSlot[] {
            nodeattr$events, nodeattr$action, ENode.nodeattr$ident, ENode.nodeattr$qualified, ENode.nodeattr$primary_expr, ENode.nodeattr$super_expr, ENode.nodeattr$symbol, ENode.nodeattr$type_lnk, ENode.nodeattr$dnode, ANode.nodeattr$parent
        });
    }
}

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

M>Вот такой код (я специально беру пример попроще, а то большой фиг разберемся)

M>

M>...
M>

M>Превращается в

M>

M>...
M>

То есть это просто автоматическая генерация кода?

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

V>То есть это просто автоматическая генерация кода?

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

    @nodeAttr
    public ASTNode∅                members;

    public rule resolveNameR(ResInfo path)
    {
        path ?= this
    ;
        path @= members
    ;
        path.isSuperAllowed(),
        parent_set.dnode != null,
        path.getPrevSlotName() != "parent_set",
        path.enterSuper() : path.leaveSuper(),
        parent_set.dnode.resolveNameR(path)
    }

генерится (увы, декомпилятор плохо справляется — поэтому промежуточный, а потом
декомпилированный код)

#{
                    @static class frame$$ extends rule {
                                        frame$$(){}
                                        int bt$;
                                        int bt$0;
                                        int bt$1;
                                        kiev.vtree.NodeSpaceEnumerator $iter$0;
                                        kiev.stdlib.rule $rc$frame$1;
                    }
                    frame$$ $env;
                    int bt$;
                    if ( $env$ == null ) {
                                        $env = new frame$$();
                                        bt$ = 0;
                                        goto enter$1;
                    } else {
                                        $env = ($cast frame$$) $env$;
                                        bt$ = $env.bt$;
                    }
                    switch ( bt$ ) {
case 0 :
                    return null;
enter$1:
                    if ( path.$is_bound )
                                        goto bound$1;
                    if ( ! path.$bind_chk(this) )
                                        goto enter$2;
                    $env.bt$0 = bt$;
                    bt$ = 1;
                    $env.bt$ = bt$;
                    return $env;
case 1 :
                    path.$unbind();
                    bt$ = $env.bt$0;
                    goto enter$2;
bound$1:
                    if ( ! path.equals(this) )
                                        goto enter$2;
                    $env.bt$ = bt$;
                    return $env;
enter$2:
                    if ( path.$is_bound )
                                        goto bound$2;
                    $env.bt$0 = bt$;
                    bt$ = 2;
                    $env.$iter$0 = members.elements();
case 2 :
                    while ( $env.$iter$0.hasMoreElements() ) {
                                        if ( ! path.$rebind_chk($env.$iter$0.nextElement()) )
                                                            continue #id""#;
                                        $env.bt$ = bt$;
                                        return $env;
                    }
                    $env.$iter$0 = null;
                    path.$unbind();
                    bt$ = $env.bt$0;
                    goto enter$3;
bound$2:
                    $env.bt$0 = bt$;
                    bt$ = 2 + 1;
                    if ( members.contains(path.$var) ) #{
                                        $env.bt$ = bt$;
                                        return $env;
                    }
case 2 + 1 :
                    bt$ = $env.bt$0;
                    goto enter$3;
enter$3:
                    {
                                        if ( ! ( path.isSuperAllowed() && parent_set.dnode != null && path.getPrevSlotName() != "parent_set" ) )
                                                            return null;
                    }
enter$4:
                    {
                                        $env.bt$0 = bt$;
                                        bt$ = 4;
                                        path.enterSuper();
                                        goto enter$5;
                    }
case 4 :
                    {
                                        path.leaveSuper();
                                        return null;
                    }
enter$5:
                    $env.bt$1 = bt$;
                    bt$ = 5;
case 5 :
                    if ( ! ( $env.$rc$frame$1 = parent_set.dnode.resolveNameR(path) ) ) #{
                                        bt$ = $env.bt$1;
                                        goto case bt$;
                    }
                    $env.bt$ = bt$;
                    return $env;
                    }
                    return null;
}

    public rule resolveNameR(rule $env$, ResInfo path)
    {
        if($env$ != null) goto _L2; else goto _L1
_L1:
        static class frame.. extends rule
        {

            int bt$;
            int bt$0;
            int bt$1;
            NodeSpaceEnumerator $iter$0;
            rule $rc$frame$1;

            frame..()
            {
            }
        }

        frame.. $env;
        int bt$;
        $env = new frame..();
        bt$ = 0;
        if(!path.is$is_bound())
        {
            if(path.$bind_chk(this))
            {
                $env._fld0 = bt$;
                bt$ = 1;
                $env. = bt$;
                return $env;
            }
        } else
        if(path.equals(this))
        {
            $env. = bt$;
            return $env;
        }
          goto _L3
_L2:
        $env = (frame..)$env$;
        bt$ = $env.;
        bt$;
_L16:
        JVM INSTR tableswitch 0 5: default 392
    //                   0 68
    //                   1 111
    //                   2 177
    //                   3 267
    //                   4 329
    //                   5 347;
           goto _L4 _L5 _L6 _L7 _L8 _L9 _L10
_L5:
        return (rule)null;
_L6:
        path.$unbind();
        bt$ = $env._fld0;
_L3:
        if(!path.is$is_bound()) goto _L12; else goto _L11
_L12:
        $env._fld0 = bt$;
        bt$ = 2;
_L7:
        for($env._fld0 = new NodeSpaceEnumerator(getMembers()); $env._fld0.hasMoreElements();)
            if(path.$rebind_chk((ASTNode)$env._fld0.nextElement()))
            {
                $env. = bt$;
                return $env;
            }

        $env._fld0 = null;
        path.$unbind();
        bt$ = $env._fld0;
          goto _L13
_L11:
        $env._fld0 = bt$;
        bt$ = 3;
        if(NodeSpaceEnumerator.contains(getMembers(), path.get$var()))
        {
            $env. = bt$;
            return $env;
        }
_L8:
        bt$ = $env._fld0;
_L13:
        if(!path.isSuperAllowed() || (BindingSet)getParent_set().getDnode() == null || path.getPrevSlotName() == "parent_set")
            return (rule)null;
        $env._fld0 = bt$;
        bt$ = 4;
        path.enterSuper();
        $env._fld1 = bt$;
        bt$ = 5;
          goto _L10
_L9:
        path.leaveSuper();
        return (rule)null;
_L10:
        if(($env._fld1 = ((BindingSet)getParent_set().getDnode()).resolveNameR($env._fld1, path)) != null) goto _L15; else goto _L14
_L14:
        bt$ = $env._fld1;
        bt$;
          goto _L16
_L15:
        $env. = bt$;
        return $env;
_L4:
        return (rule)null;
    }

Это не простая генерация кода. Это компиляция из логического языка в явовский байткод. Этот логический код полностью интегрирован с явой — из явы можно вызывать эти методы, можно из методов вызывать явовские методы и использовать явовские выражения. Через этот логический язычёк у меня в компиляторе сделан резолвинг имён и auto-completition (поскольку он позволяет находить не просто первый ответ, но и все ответы, как любой нормальный логический язык программирования).

Реализуется он всё теми-же макросами и добавленными семантическими узлами AST дерева.

	От:	Klapaucius
	Дата:	02.09.08 09:13
	Оценка:	250 (11) +5

От:	mkizub	http://symade.tigris.org
Дата:	28.08.08 13:34
Оценка:	170 (22)

	От:	Кодёнок
	Дата:	29.08.08 08:57
	Оценка:	6 (1) +2

От:	Чистяков Влад (VladD2)	www.nemerle.org
Дата:	27.08.08 15:42
Оценка:	416 (15) +1 -1

	От:	prVovik
	Дата:	01.09.08 11:37
	Оценка:	126 (8) +7 -2

От:	Gaperton	http://gaperton.livejournal.com
Дата:	07.09.08 14:15
Оценка:	31 (4) +2

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	01.09.08 19:01
Оценка:	+6

От:	eao197	http://eao197.blogspot.com
Дата:	29.08.08 06:05
Оценка:	+4

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	01.09.08 20:45
Оценка:	+4

От:	VladD2	www.nemerle.org
Дата:	29.08.08 08:53
Оценка:	-3

От:	Sinclair	https://github.com/evilguest/
Дата:	03.09.08 05:58
Оценка:	37 (1) +1

От:	seregaa	http://blogtani.ru
Дата:	29.08.08 08:44
Оценка:	+2

От:	IT	linq2db.com
Дата:	29.08.08 18:55
Оценка:	+2

От:	oldor	http://vingrad.ru/blogs/dorozhko/
Дата:	31.08.08 13:47
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	02.09.08 08:20
Оценка:	+2

	От:	GlebZ
	Дата:	30.08.08 10:02
	Оценка:

	От:	VoidEx
	Дата:	30.08.08 15:55
	Оценка:	+1 -1

	От:	WolfHound
	Дата:	30.08.08 13:21
	Оценка:	-2

От:	Valery A. Boronin	linkedin.com/in/boronin
Дата:	06.10.08 01:50
Оценка:	42 (1)

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	01.09.08 10:19
Оценка:

От:	Aikin	kavaleu.ru
Дата:	02.09.08 11:23
Оценка:	+1

От:	Plague	177230800
Дата:	29.08.08 14:11
Оценка:

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	01.09.08 03:13
Оценка:

	От:	Священный Воин
	Дата:	01.09.08 11:31
	Оценка:

От:	cadet354	my twitter
Дата:	02.09.08 06:01
Оценка:

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	02.09.08 21:50
Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	03.09.08 06:42
Оценка:

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	08.09.08 11:20
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	08.09.08 12:08
Оценка:

От:	Димчанский	http://dimchansky.github.io/
Дата:	12.09.08 06:46
Оценка: