Почему C# не Немерле - Философия программирования

Сразу три дисклаймера:
1) Ответа на сабж я не знаю
2) Прошу заранее извинить, если кому то покажется, что в письме слишком много "я". Если это невозможно — можно дальше просто не читать.
3) Спорить, особенно опускаясь до демагогии и просто хамства, мне совсем не хочется, и я буду стараться этого не делать. Единственная цель сего сообщения — рассказать о том, что я думаю по поводу сабжа тем, кому это действительно интересно знать.

Итак, по ходу обсуждения я увидел примерно две точки зрения, где следует искать ответ на сабжевый вопрос. Попытаюсь их сформулировать:
1) Ответ следует искать в личных особенностях Хейлсберга, а именно недостаточном образовании (он не знал что такое ФП), узком кругозоре (он не увидел Немерле и всю его перспективу), нежелании признавать свои ошибки, неумении делать по настоящему новое (они ни одного по настоящему нового языка не придумал), плохого восприятия нового (он только сейчас заговорил о МП).
2) На дизайн C# оказали влияние ряд факторов, как то: готовность "большого" комьюнити ака мейнстрима к восприятию изменений, необходимости считаться с наличием большого количества "индусов", принятие во внимания не только сугубо программистких задач, но и, к примеру, проблем организации проекта, поддержания стабильного качества огромных массивов кода, вопросов эволюции кода. Кроме того, немаловажным фактором является политическая и финансовая ситуация в МС в целом и в C# team в частности.
Как несложно понять — с очень высокой степенью вероятности не знают ответа на вопрос (обратить внимание на выделение, лопата там) сторонники обеих точек зрения. Потому что, совершенно точно, никто из них не является Хейлсбергом, не может залезть ему в голову, с очень высокой вероятностью не является близким его другом, и даже, боюсь, диплома психоаналитика склорее всего ни у кого нет. Точно так же, очень вряд ли кто то здесь присутствовал на большинстве совещаний, на которых предлагались нововведения и принимались решения о дизайне языка.
Как нетрудно догадаться, я придерживаюсь второго варианта. Почему? Нет, совсем не потому что я считаю Хейлсберга непогрешимым и являюсь его фанатом, как тут кое кто утверждает. Все намного проще. Если идти по первому варианту — а куда мы, собственно, придем? Ну то есть — вот мы тут доказали хотя бы для самих себя — да, Хейлсберг (далее, по списку). И что? Какие бенефиты мы в итоге получим? Мое извращенное воображение не может придумать ничего, кроме того, что это позволит себе польстить в стиле "вот насколько я круче самого Хейлсберга, жаль что мне не повезло так, как ему".
А вот хождение по второму пути мне кажется несколько более перспективным, потому что, основываясь на этих рассуждениях (и знания неких подробностей внутренней кухни, которые я получил путем злоупотребления своим статусом MVP и просто хорошего человека) можно попытаться спрогнозировать, куда поведет кривая (дорожка).
Ну, вроде бы все, что я хотел здесь сказать.

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

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

AVK>Ну, вроде бы все, что я хотел здесь сказать.
Можно дополнить? Может быть ввести на некоторое время мораторий на Немерлевые темы как в своё время был мораторий на "украинские" темы?

А то уже надоело, честно говоря — все тут уже знают мнения всех и просто так их не изменят.

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

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

Очень хорошо. Но я бы ещё дополнил, что на C# неизбежно оказывает влияние маркетинговая политика MS. И тогда, ИМХО, вообще всё становится на свои места (интересно было бы посмотреть, как VladD2 будет клеймить маркетинг MS, в прочем, я ёрничаю). По существу, MS балансирует на грани между академичной компактностью языка, необходимостью удовлетворить перечисленным тобой выше в п.2 требованиям и его приемлемостью для "широких масс". Поэтому, кстати, C# не может стать ни Nemerle, ни Lisp-ом. А сам Хейлсберг в данном случае вполне подходящая фигура эдакого демократично настроенного верховного разработчика, в меру консервативного... Но по сути, его личные качества никакого отношения к характеру самого C# не должны иметь. Кстати, как и мнение Страуструпа не определяет решение комитета.

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

Из этого получается (попытаю счастья в ипостаси прогнозиста), что C# всегда будет представлять некий компромисс между плодами исследований в области языков, рыночным положением MS и представлением MS о "майнстриме". Надёжно определяемых факторов, имхо, тут немного. Известно, что:

— MS до какой-то степени договорилась с Sun, так что некоторое время C# и Java, скорее всего, будут похожи друг на друга. Во всяком случае, у них будут развиваться средства интероперабельности;

— Есть "некоторая истерика" по поводу финансового кризиса, это, вероятно, будет способствовать некоторому снижению цен на высококвалифицированный персонал (да! язык может быть относительно сложным);

— Телекоммуникационный сектор не остановится в своём развитии (здравствуйте, FP-шные наработки Ericsson! Веб-шняга находится где-то здесь же).

Дальше пока "мысль останавливается" (c).

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

ГВ>Очень хорошо. Но я бы ещё дополнил, что на C# неизбежно оказывает влияние маркетинговая политика MS.

Так про политику я писал.

ГВ>интересно было бы посмотреть, как VladD2 будет клеймить маркетинг MS

Он уже, ЕМНИП, как то это делал, неинтересно.

ГВ>, в прочем, я ёрничаю). По существу, MS балансирует на грани между академичной компактностью языка, необходимостью удовлетворить перечисленным тобой выше в п.2 требованиям и его приемлемостью для "широких масс". Поэтому, кстати, C# не может стать ни Nemerle, ни Lisp-ом.

Ну, да.

ГВ> А сам Хейлсберг в данном случае вполне подходящая фигура эдакого демократично настроенного верховного разработчика, в меру консервативного... Но по сути, его личные качества никакого отношения к характеру самого C# не должны иметь.

Ну, в МС все таки личность имеет немаловажное значение. С другой стороны, ты прав. Не думаю что это страшный секрет, Хейлсберг далеко не вершитель судеб C#, и определяет он его будущее не единолично. Текущее состояние — баланс интересов довольно большого количества народа.

ГВ>Из этого получается (попытаю счастья в ипостаси прогнозиста), что C# всегда будет представлять некий компромисс между плодами исследований в области языков, рыночным положением MS и представлением MS о "майнстриме".

Ну, это очевидно. Интересна конкретика, а это уже сложнее.

ГВ>- MS до какой-то степени договорилась с Sun

Из того что я знаю — крайне сомнительно.

ГВ>, так что некоторое время C# и Java, скорее всего, будут похожи друг на друга. Во всяком случае, у них будут развиваться средства интероперабельности;

Ни МС, ни Сан таких средств не предоставляют. J# благополучно сдох, а со стороны Сана так ничего и не было. Веб-сервисы на интероперабильность тянут слабо. IKVM — независимая от обоих штука.

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

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

ГВ>> А сам Хейлсберг в данном случае вполне подходящая фигура эдакого демократично настроенного верховного разработчика, в меру консервативного... Но по сути, его личные качества никакого отношения к характеру самого C# не должны иметь.

AVK>Ну, в МС все таки личность имеет немаловажное значение. С другой стороны, ты прав. Не думаю что это страшный секрет, Хейлсберг далеко не вершитель судеб C#, и определяет он его будущее не единолично. Текущее состояние — баланс интересов довольно большого количества народа.

Согласен. Тем смешнее выглядят рассуждения о том, какой Хейлсберг непутёвый.

ГВ>>Из этого получается (попытаю счастья в ипостаси прогнозиста), что C# всегда будет представлять некий компромисс между плодами исследований в области языков, рыночным положением MS и представлением MS о "майнстриме".
AVK>Ну, это очевидно. Интересна конкретика, а это уже сложнее.

В принципе, можно поиграться в аналитиков, кто ж нам запретит?

ГВ>>- MS до какой-то степени договорилась с Sun
AVK>Из того что я знаю — крайне сомнительно.
ГВ>>, так что некоторое время C# и Java, [...] у них будут развиваться средства интероперабельности;
AVK>Ни МС, ни Сан таких средств не предоставляют. J# благополучно сдох, а со стороны Сана так ничего и не было. Веб-сервисы на интероперабильность тянут слабо. IKVM — независимая от обоих штука.

Честно говоря, мне самому трудно однозначно судить. Я сейчас пользуюсь воспоминаниями о дискусси, кажется, двухлетней давности, что ли. Там муссировался договор MS и Sun относительно дружбы против IBM. Хрен его знает. Они могли и пересмотреть свои стратегии в виду финансовых катаклизмов. С другой стороны, IBM — это такая конструкция, которая намертво цепляет своих клиентов и, как я понимаю, оглядывается только на мнение своих подразделений. Иными словами, откусить занятый IBM сегмент корпоративного рынка по-прежнему имеет смысл. Но у MS нет приличного сервера БД, сравнимого с DB2, а у Sun — пользовательской аудитории. Так что, имхо, MS и Sun на роду написано стать заклятыми друзьями.

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

AVK>Ну, вроде бы все, что я хотел здесь сказать.

Отпевная вышла на славу.

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

Простой пример: когда вышел первый шарп, было очень много воя по поводу отсутствия checked exceptions. Основные две версии произошедшего были "не смогли сделать как в яве" и "не знали, как это сделано в яве" оказались неверными. Оказывается, было проведено масштабное исследование практики применения checked exceptions, и только после этого было принято взвешенное решение. Вот это исследование я и отношу к хардкорному маркетингу.

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

Вот на (не к ночи будь помянутом) дельфи была построена прекрасная среда и библиотека разработки определенного класса приложений. Без языка в том виде, как его придумал Хейльсберг, VCL была бы невозможна.

Проверкой и доказательством состоятельности шарпа и дотнета как платформы является не наличие конечных приложений, а наличие промежуточных решений — фреймворков. Вот, к примеру, совершенно неожиданным образом лямбды из третьего шарпа оказались полезны не только для типизированного доступа к сиквел серверу, но и для того, чтобы строить статически верифицируемые гиперссылки в MVC Framework.

Для доказательства состоятельности Nemerle как современного языка необходимо построить на нем некий фреймворк для построения приложений.
Раз макросы так сильны — значит, можно делать крутые вещи, так?
Пока что всё, что я поверхностно видел, сводилось к воспроизводству фич шарпа, либо каким-то локальным достижениям, не очень важным с точки зрения прикладного программиста. Что у нас там есть? String Templates? Не вполне убедительно. Особенно забавно наблюдать за топиками Breaking Changes, как только дело доходит до реального применения этого фреймворка.

Я не настаиваю на том, чтобы немедленно конкурировать с MVC Framework. (Просто он работает как раз в той области, в которой я совершенно случайно разбираюсь).
Давайте покажем какой-нибудь фреймворк для мегапараллелизма а-ля Erlang, или более удобный аналог BLToolkit, или фреймворк для построения WPF приложений, или еще для чего-нибудь такого, чтобы мировая общественность поняла: вот он, свет новых знаний.

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

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

ГВ>Честно говоря, мне самому трудно однозначно судить. Я сейчас пользуюсь воспоминаниями о дискусси, кажется, двухлетней давности, что ли. Там муссировался договор MS и Sun относительно дружбы против IBM.

Это все красивые бумажки. Теоретически, они могут повлиять на распределение денег, но не на уровне отдельных фич языка. Максимум — это будет учитываться при определении судьбы целых проектов целиком. Короче, на уровне стратегии, а не тактики.

ГВ> Хрен его знает. Они могли и пересмотреть свои стратегии в виду финансовых катаклизмов.

Финансовые катаклизмы пока что МС не касаются почти никак.

ГВ> Но у MS нет приличного сервера БД, сравнимого с DB2

Это смотря что включать в понятие "приличный"

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

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

ГВ>Очень хорошо. Но я бы ещё дополнил, что на C# неизбежно оказывает влияние маркетинговая политика MS. И тогда, ИМХО, вообще всё становится на свои места (интересно было бы посмотреть, как VladD2 будет клеймить маркетинг MS, в прочем, я ёрничаю). По существу, MS балансирует на грани между академичной компактностью языка, необходимостью удовлетворить перечисленным тобой выше в п.2 требованиям и его приемлемостью для "широких масс".

Вот это действительно очень точная характеристика происходящего. На самом деле MS нужен относительно простой, скажем так, бизнес-ориентированный язык, прекрасно подходящий для решения mainstream-задач (в роли к-го даже вполне мог бы выступать C# 1.0) и другой язык, несколько более "академический". А существующее разделение между языками не очень понятно. Вроде бы собирались в роли академического сделать C++/CLI — но во-первых он явно несет на себе пережитки еще черт знает какой эпохи, независимо от того с каким ключами его компилируешь, да и в качестве площадки для "прогрессивных" фич платформа старого С++ как-то не особо подходит. Бейсик как более мейнстрим — по кр. мере именно так они его хотят показать — на самом деле не так сильно от C# отличается-то.
По большому счету им нужен C# и какой-нибудь С#++. Может, они в конце концов и придут к этому. И кстати я не удивляюсь, если MS даже в конце концов купит Немереле

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

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

ВВ>По большому счету им нужен C# и какой-нибудь С#++. Может, они в конце концов и придут к этому. И кстати я не удивляюсь, если MS даже в конце концов купит Немереле

У них уже появился такой — F#

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

ВВ>>По большому счету им нужен C# и какой-нибудь С#++. Может, они в конце концов и придут к этому. И кстати я не удивляюсь, если MS даже в конце концов купит Немереле

FR>У них уже появился такой — F#

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

К тому же F# чисто функциональный язык. И с момента появления не было замечено попыток хотя бы просто добавить его поддержку в IDE.

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

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

ВВ>Честно, не воспроизведу хронологию, но лично я про F# услышал значительно раньше чем про Немерле. Так что "уже появился" несколько неправильный термин

Уже появился, в том смысле что ms его официально выбрало.

ВВ>К тому же F# чисто функциональный язык. И с момента появления не было замечено попыток хотя бы просто добавить его поддержку в IDE.

F# как и его предок Ocaml гибридные языки, и на них можно без проблем писать и чисто императивно.
В следующую студию обещают добавить как официальный язык, а интеграция и сейчас доступна.

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

FR>F# как и его предок Ocaml гибридные языки, и на них можно без проблем писать и чисто императивно.

Возможно, я не очень хорошо себе представляю возможности F#, но мне почему-то кажется, что он не сможет заменить ни Немерле, ни C#

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

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

ВВ>Возможно, я не очень хорошо себе представляю возможности F#, но мне почему-то кажется, что он не сможет заменить ни Немерле, ни C#

На Ocaml можно писать как на си или паскале:

let sum n = 
    let s = ref 0 and i = ref 0 in 
    while !i < n do
        s := !s + !i;
        i := !i + 1;
        done;
    !s;;

На F# тоже, и они оба C# уж точно заменят и будут намного выразительнее.
С Немерле F# по выразительности (исключая макросы) примерно на одном уровне.

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

ГВ>>Честно говоря, мне самому трудно однозначно судить. Я сейчас пользуюсь воспоминаниями о дискусси, кажется, двухлетней давности, что ли. Там муссировался договор MS и Sun относительно дружбы против IBM.

AVK>Это все красивые бумажки. Теоретически, они могут повлиять на распределение денег, но не на уровне отдельных фич языка. Максимум — это будет учитываться при определении судьбы целых проектов целиком. Короче, на уровне стратегии, а не тактики.

Согласен. Но тактика, так или иначе подчиняется стратегии.

ГВ>> Хрен его знает. Они могли и пересмотреть свои стратегии в виду финансовых катаклизмов.
AVK>Финансовые катаклизмы пока что МС не касаются почти никак.

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

ГВ>> Но у MS нет приличного сервера БД, сравнимого с DB2
AVK>Это смотря что включать в понятие "приличный"

Такой, который бы уверенно конкурировал с DB2 на больших массивах.

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

S>Простой пример: когда вышел первый шарп, было очень много воя по поводу отсутствия checked exceptions. Основные две версии произошедшего были "не смогли сделать как в яве" и "не знали, как это сделано в яве" оказались неверными. Оказывается, было проведено масштабное исследование практики применения checked exceptions, и только после этого было принято взвешенное решение. Вот это исследование я и отношу к хардкорному маркетингу.

Согласен. ИМХО, как раз таким хардкорным маркетингом и обусловлена последовательность введения фич в C#. Продолжая это имхо хочу сказать, что кажется, будто сейчас MS снова нащупывает дальнейший путь развития. Если в случае C# 1.0/2.0 дорога была уже протоптана явой и C++, то сейчас, по-моему, они пытаются накрыть пространство задач телекома. Во всяком случае, под такое предположение подходит и появление WCF, и поддержка функционального стиля. Тогда, по идее, следующий большой шаг должен быть где-то в области параллелизма.

S>Двигаясь далее, хотелось бы отметить, что один из основных критериев качества языка — это возможность строить на нём фреймворки.

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

P.S.: Если говорить о макросах, подобных Lisp-овым, то, как мне кажется, в широкое употребление их вряд ли введут. Инструмент, спору нет, мощный, но будь я тем, кто планирует продукт для пресловутых "индусов" — не рискнул бы такое разрешать. Хорошо, конечно, завоевать симпатии гиков, но весовые соотношения потерянной и приобретённой аудиторий сильно отличаются — приобретение не равно потере: масса "индусов" сбежит на более простые языки, которые будут не так сильно склонять к сюрпризам. А когда язык расширяется медленно, плавно и с помощью едва ли не косметических изменений, то можно добиться, в общем-то, много: прежде всего, стабильного community, наработки определённых паттернов использования, короче говоря — стабильности в широком смысле этого слова.

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

ГВ>то сейчас, по-моему, они пытаются накрыть пространство задач телекома. Во всяком случае, под такое предположение подходит и появление WCF, и поддержка функционального стиля.

ИМХО тут ты не прав. ИМХО же, из-за того, что незнаком с подлобностями. ФП нарисовался на волне LINQ, а WCF ... Он закладывался в 2003 году и на фоне оглушительного пука WS и сырого состояния ремоутинга создание нового RPC фреймворка выглядело абсолютно логичным шагом.
А если вспомнить, что был еще и WPF, то, думаю, стратегия была очень простой — закрыть очевидные и самые болезненные дырки.

ГВ> Тогда, по идее, следующий большой шаг должен быть где-то в области параллелизма.

Это очевидно. И подтверждается как публичными заявлениями МС, так и ее действиями. К примеру, в состав штатной библиотеки .NET 4 включена библиотечка ParallelFX.
Проблема тут только в одном — я пока не видел достаточно интересного способа решить эту задачку качественно, и PFX не исключение. Хотя, безусловно, набор основных мультипоточных примитивов (то, что внутре CDS) должен быть в составе платформы обязательно.

ГВ>Вот тут, мне кажется, ты ошибаешься. Фреймворк можно построить на любом языке кроме самых специфичных.

Я дума, Синклер имел ввиду немножко другое. Хейлсберг проектировал язык с учетом создания фреймворка. Т.е., к примеру, published в Дельфи был введен исключительно для поддержки дизайн-тайма. В шарпе сознательно убраны все фичи, из-за которых тяжело было бы реализовать автоматический рефакторинг и прочие инструменты манипуляции с кодом. И т.д. В академических кругах такое, мягко говоря, не принято.

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

+1

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

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

ГВ>>то сейчас, по-моему, они пытаются накрыть пространство задач телекома. Во всяком случае, под такое предположение подходит и появление WCF, и поддержка функционального стиля.

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

Ну не совсем. Тут я в курсе более или менее. Может быть, несколько перегнул сейчас с теорией заговора, то есть — стратегического маркетинга.

ГВ>> Тогда, по идее, следующий большой шаг должен быть где-то в области параллелизма.

AVK>Это очевидно. И подтверждается как публичными заявлениями МС, так и ее действиями. К примеру, в состав штатной библиотеки .NET 4 включена библиотечка ParallelFX.
AVK>Проблема тут только в одном — я пока не видел достаточно интересного способа решить эту задачку качественно, и PFX не исключение. Хотя, безусловно, набор основных мультипоточных примитивов (то, что внутре CDS) должен быть в составе платформы обязательно.

Это, как раз, интересно. Пока получается, что им чуть ли не CLR придётся основательно переколпачить.

[...]

С остальным согласен.

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

ГВ>Это, как раз, интересно. Пока получается, что им чуть ли не CLR придётся основательно переколпачить.

Может и придется. Но пока даже неясно, в каком направлении надо колпачить.

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

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

S>Проверкой и доказательством состоятельности шарпа и дотнета как платформы является не наличие конечных приложений, а наличие промежуточных решений — фреймворков. Вот, к примеру, совершенно неожиданным образом лямбды из третьего шарпа оказались полезны не только для типизированного доступа к сиквел серверу, но и для того, чтобы строить статически верифицируемые гиперссылки в MVC Framework.

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

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вот тут, мне кажется, ты ошибаешься. Фреймворк можно построить на любом языке кроме самых специфичных.
Ну да. Только вот на плюсах, как ни пиши — получается MFC

Воспроизвести MVC Framework, к примеру, на Дельфи — нереально. Можно сделать отдаленно похожую хрень, но именно что отдаленно.

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

Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Вот тут, мне кажется, ты ошибаешься. Фреймворк можно построить на любом языке кроме самых специфичных.

S>Ну да. Только вот на плюсах, как ни пиши — получается MFC

S>Воспроизвести MVC Framework, к примеру, на Дельфи — нереально. Можно сделать отдаленно похожую хрень, но именно что отдаленно.
Cудя по количеству минусов, я зря не написал "ASP.NET" перед MFC Framework.
Если же минусующие и так всё поняли правильно, но несогласны, то я предлагаю им привести фрагмент кода на Delphi или C++, который формирует по вызову метода линк.
То есть аналог вот этого:

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

S>>Ну да. Только вот на плюсах, как ни пиши — получается MFC

S>>Воспроизвести MVC Framework, к примеру, на Дельфи — нереально. Можно сделать отдаленно похожую хрень, но именно что отдаленно.
S>Cудя по количеству минусов, я зря не написал "ASP.NET" перед MFC Framework.

Антон, ты определись -- MFC (Microsoft Foundation Classes) или MVC (Model View Controller).

S>Если же минусующие и так всё поняли правильно, но несогласны, то я предлагаю им привести фрагмент кода на Delphi или C++, который формирует по вызову метода линк.
S>То есть аналог вот этого:
S>

А как нибудь словами эту задачу сформулировать можно? Для далеких от Web-программирования людей.

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

E>Антон, ты определись -- MFC (Microsoft Foundation Classes) или MVC (Model View Controller).
MVC

S>>Если же минусующие и так всё поняли правильно, но несогласны, то я предлагаю им привести фрагмент кода на Delphi или C++, который формирует по вызову метода линк.
S>>То есть аналог вот этого:
S>>

E>А как нибудь словами эту задачу сформулировать можно? Для далеких от Web-программирования людей.
1. Есть routing engine. Он умеет анализировать входящие HTTP запросы и сопоставлять их вызовам методов контроллеров.
Например, словив
/Search/Beverages/2
он понимает, что нужно вызвать SearchController.Results("Beverages", 2).
То есть всю рутинную работу по разбору строки запроса выполняет фреймворк; твоему коду достаются уже типизированные параметры.
Правила роутинга описываются отдельно от твоего кода и очень гибким способом. Например, тот же результат мог бы быть доступен по адресу
/Search.ashx?Group=Beverages&page=2
2. Теперь встает обратная задача: как обеспечить корректность ссылок на страничках, которые генерирует твое приложение?
Приведенный фрагмент кода делает именно это: находит правило роутинга, приводящее к нужному методу, и подставляет параметры вызова обратно в URL.
Самое замечательное — то, что компилятор следит за корректностью кода. То есть состряпать набор параметров, несовместимый с сигнатурой целевого метода, не получится. За согласованностью маппинга следит фреймворк — оба преобразования выполняются через одну и ту же таблицу правил.

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

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

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

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

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

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

Говорить, что "какое-то дерьмо так разрекламировали" — ну, значит, вообще ничего в маркетинге не понимать. Нельзя разрекламировать дерьмо. Если "дерьмо" покупают — значит, его ТТХ из-за которых он "дерьмо" не так важны, и всем на них плевать. Раз продукт покупают — значит он удовлетворяет чью-то потребность. Если им довольны — значит он делает это хорошо. Бывает, что продукт покупают, и им не пользуются — так часто бывает с прикольными гарджетами, например. Стало быть, он никакую _реальную_ потребность не удовлетворяет.

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

Слыш, братва, они хотят отобрать у нас наши лопаты!

О чем это я? Ну это, на не начинается, на мелре заканчивается

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

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

Слыш, братва, они хотят отобрать у нас наши лопаты!

О чем это я? Ну это, на не начинается, на мелре заканчивается

.

А я, грешным делом, подумал, что начинается на ли, а заканчивается на х

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

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

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

E>>Антон, ты определись -- MFC (Microsoft Foundation Classes) или MVC (Model View Controller).
S>MVC

Ну, мой минус относился к фразе:

Ну да. Только вот на плюсах, как ни пиши — получается MFC

Далеко не всегда на C++ получаются такие здоровенные комбайны, как MFC.

S>2. Теперь встает обратная задача: как обеспечить корректность ссылок на страничках, которые генерирует твое приложение?
S>Приведенный фрагмент кода делает именно это: находит правило роутинга, приводящее к нужному методу, и подставляет параметры вызова обратно в URL.
S>Самое замечательное — то, что компилятор следит за корректностью кода. То есть состряпать набор параметров, несовместимый с сигнатурой целевого метода, не получится. За согласованностью маппинга следит фреймворк — оба преобразования выполняются через одну и ту же таблицу правил.

Не зная, как в compile-time работает конструкция

Html.ActionLink<SearchController>(..., s => s.Result( "...", 2 ) )

я не могу ответить.

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

E>Далеко не всегда на C++ получаются такие здоровенные комбайны, как MFC.

Ага, иногда получается boost

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

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

AVK>Ага, иногда получается boost

Угу в бусте немало компактных красивых штучек

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

E>>Далеко не всегда на C++ получаются такие здоровенные комбайны, как MFC.

AVK>Ага, иногда получается boost

И причем тут boost и MFC? boost — вообще не ГУЙ библиотека. А вот насчет комбайнов, то мне нравятся WTL и wxWidgets

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

S>Если же минусующие и так всё поняли правильно, но несогласны, то я предлагаю им привести фрагмент кода на Delphi или C++, который формирует по вызову метода линк.
S>То есть аналог вот этого:
S>

Пожалуй, для начала придётся взять C++ server pages и помудрить с оным. Сгенерить описание по сигнатуре, в общем, не ахти, какая сложная задача. Ну, дальше, по-видимому, нужно свести хранение и распознавание ссылок и связей к какому-то общему хранилищу и т.п.

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

ГВ>Пожалуй, для начала придётся взять C++ server pages и помудрить с оным. Сгенерить описание по сигнатуре, в общем, не ахти, какая сложная задача.
Ну-ну. Там не в сигнатуре дело. А в параметрах вызова. Которые могут быть и не константами. Так что удачи.

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

ГВ>>Пожалуй, для начала придётся взять C++ server pages и помудрить с оным. Сгенерить описание по сигнатуре, в общем, не ахти, какая сложная задача.
S>Ну-ну. Там не в сигнатуре дело. А в параметрах вызова. Которые могут быть и не константами. Так что удачи.

Да ладно тебе.

Можно и по параметрам.

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

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

ГВ>>Пожалуй, для начала придётся взять C++ server pages и помудрить с оным. Сгенерить описание по сигнатуре, в общем, не ахти, какая сложная задача.
S>Ну-ну. Там не в сигнатуре дело. А в параметрах вызова. Которые могут быть и не константами. Так что удачи.
отстаешь от жизни,сча линки уже можно так объявлять <%= Html.ActionLink(t.Title, "Thread", new{ id=t.ID}, new{@class="f12" } ) %>

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

K>отстаешь от жизни,сча линки уже можно так объявлять <%= Html.ActionLink(t.Title, "Thread", new{ id=t.ID}, new{@class="f12" } ) %>

И где тут проверка типов? Если я вместо Thread напишу "Thred", всё пропало? Или вместо new { id = t.ID } напишу new { id = "oops" }?

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

Y>И причем тут boost и MFC? boost — вообще не ГУЙ библиотека.

А ASP.NET MVC, надо думать, ГУЙ?

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

Здравствуйте, kkolyan, Вы писали:
K>отстаешь от жизни,сча линки уже можно так объявлять <%= Html.ActionLink(t.Title, "Thread", new{ id=t.ID}, new{@class="f12" } ) %>
Не отстаю. Это было описано по соседству, но мне так меньше нравится.
Во-первых, это длиннее, во-вторых, нет проверки типов компилятором.

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

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да ладно тебе.

Можно и по параметрам.
Пример в студию

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

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

S>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Да ладно тебе.

Можно и по параметрам.
S>Пример в студию

Почти любой сериализатор так работает.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Почти любой сериализатор так работает.

Что? Сериализатор вызовов методов?
И вот так тоже будет работать?

foreach(int page in pages)
{
  yield return Url.Action<SearchController>(s => s.Results("Beverages", page);
}

Я в это не поверю, пока не увижу работающий пример.

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

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

S>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Почти любой сериализатор так работает.

S>Что? Сериализатор вызовов методов?

Ты видишь принципиально нерешаемые проблемы?

S>И вот так тоже будет работать?
S>

S>foreach(int page in pages)
S>{
S>  yield return Url.Action<SearchController>(s => s.Results("Beverages", page);
S>}
S>

S>Я в это не поверю, пока не увижу работающий пример.

Это не вопрос веры. Это вопрос постановки задачи. Что делает твой фрагмент? В смысле — с колокольни пользователя?

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

ГВ>Ты видишь принципиально нерешаемые проблемы?
Да, вижу. Я не понимаю, каким образом компилятор С++ сможет извлечь информацию о вызове метода из вызова метода и вместо выполнения вызова отдать эту информацию в некий фреймворк.
В шарпе для этого использованы Expression Trees. Я не припоминаю никакого аналога этого механизма в C++.
ГВ>Это не вопрос веры. Это вопрос постановки задачи. Что делает твой фрагмент? В смысле — с колокольни пользователя?
Он генерирует список ссылок, которые приведут к выполнению вызова соответствующего метода контроллера.
Вот почитай собсно статью: http://weblogs.asp.net/scottgu/archive/2007/12/03/asp-net-mvc-framework-part-2-url-routing.aspx. То место, где про Constructing Outgoing URLs.

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

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

ГВ>>Ты видишь принципиально нерешаемые проблемы?
S>Да, вижу. Я не понимаю, каким образом компилятор С++ сможет извлечь информацию о вызове метода из вызова метода и вместо выполнения вызова отдать эту информацию в некий фреймворк.

Разумеется, я имею в виду не вызов в прямом смысле этого слова (то есть object->method(parameter); ), а некий аналог boost::bind/boost::function, что-то вроде bind(&Object::method, object, parameter). Такая переформулировка позволит и вызвать метод по месту, и в то же время — сериализовать описание вызова. Естественно, что синтаксически это не то же самое, что использование Expression Trees. Ну и будут, разумеется, свои сложности с поиском нужного экземпляра объекта. В принципе, очень похоже на игрища с ORM, только в профиль.

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

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

Слыш, братва, они хотят отобрать у нас наши лопаты!

О чем это я? Ну это, на не начинается, на мелре заканчивается

.

AVK>А я, грешным делом, подумал, что начинается на ли, а заканчивается на х

.

Ну, вообще, много какие гики хотят захватить власть на миром

. Вон, по 2х2 идет цельный мультсериал, например, про двух мышей, которые в каждой серии хотят достичь мирового господства.

http://rutube.ru/tracks/96353.html?v=b79cd6a8eded09d970f05c7f9db77387

— Чем мы будем заниматься сегодня вечером, Брэйн?
— Тем же, чем и всегда, Пинки. Попробуем завоевать мир!

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

ГВ>Разумеется, я имею в виду не вызов в прямом смысле этого слова (то есть object->method(parameter); ), а некий аналог boost::bind/boost::function, что-то вроде bind(&Object::method, object, parameter). Такая переформулировка позволит и вызвать метод по месту, и в то же время — сериализовать описание вызова. Естественно, что синтаксически это не то же самое, что использование Expression Trees. Ну и будут, разумеется, свои сложности с поиском нужного экземпляра объекта. В принципе, очень похоже на игрища с ORM, только в профиль.
Ок, я не знаток буста. Возможно, он и позволит такое изобразить. Но пока что мне непонятно, как именно это будет работать. Пёс с ним, с поиском нужного экземпляра — это будет потом. Сейчас важно соорудить строку.
Давай пример того, как будет записан приведенный мной код на этом гипотетическом фреймворке с использованием boost::bind и boost::function.
Хочется сравнить строгость контроля и синтаксическую целостность.

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

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

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

ГВ>>Разумеется, я имею в виду не вызов в прямом смысле этого слова (то есть object->method(parameter); ), а некий аналог boost::bind/boost::function, что-то вроде bind(&Object::method, object, parameter). Такая переформулировка позволит и вызвать метод по месту, и в то же время — сериализовать описание вызова. Естественно, что синтаксически это не то же самое, что использование Expression Trees. Ну и будут, разумеется, свои сложности с поиском нужного экземпляра объекта. В принципе, очень похоже на игрища с ORM, только в профиль.
S>Ок, я не знаток буста. Возможно, он и позволит такое изобразить. Но пока что мне непонятно, как именно это будет работать. Пёс с ним, с поиском нужного экземпляра — это будет потом. Сейчас важно соорудить строку.
S>Давай пример того, как будет записан приведенный мной код на этом гипотетическом фреймворке с использованием boost::bind и boost::function.
S>Хочется сравнить строгость контроля и синтаксическую целостность.

OK, но это не boost::bind, только подобие. Можно, в общем, добиться примерно такого синтаксиса:

<%=CreateUrl("BeveragesList", urlbind(&Object::method, createObject(), 25));%>

При условии, что метод объекта выглядит, скажем, так:

class Object
{
  public:
    void method(int);
}; // Object

urlbind — семейство шаблонных функций приблизительно такого вида:

template<typename T, typename R, typename P>
  GeneratedUrl urlbind(R (T::*method)(P), Object *pobj, P param){...}
template<typename T, typename R, typename P1, typename P2>
  GeneratedUrl urlbind(R (T::*method)(P), Object *pobj, P1 p1, P2 p2){...}

Как ты понимаешь, если сигнатура доступна, то сгенерировать функтор соответствующей структуры уже не трудно.

GeneratedUrl по идее, должен содержать такие методы (возвращать wstring грубо и некультурно, я в курсе

class GeneratedUrl
{
  public:
    virtual std::wstring getSubUrl();
    virtual std::wstring getName();
    virtual void run(); // Реализуется через operator() того функтора, который генерируется внутри urlbind.
};

Как-то так. Идея, думаю, понятна.

Кстати, Влад, глянь мультик. Тебе понравится

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

S>>Хочется сравнить строгость контроля и синтаксическую целостность.

Строгость контроля тут — на уровне обычного C++-ного контроля типов. Каких-то дополнительных описаний в самом используемом классе не требуется. Указатель можно заменить на смартпойнтер.

И ещё поправка. Метод run, скорее всего, будет выглядеть как-то так:

ГВ>

ГВ>class GeneratedUrl
ГВ>{
ГВ>  public:
ГВ>    ...
ГВ>    virtual void run(HttpOutput*);
ГВ>};
ГВ>

Он должен генерировать какой-то хтмл по идее. Соответственно, у генерируемого функтора будет немного другая сигнатура и, по-видимому, целевой класс придётся наследовать от определённого интерфейса. Но это уже детали, в общем-то.

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

FR>На F# тоже, и они оба C# уж точно заменят и будут намного выразительнее.
FR>С Немерле F# по выразительности (исключая макросы) примерно на одном уровне.

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

К слову о драйверах популярности языков программирования и платформ.

Здравствуйте, Геннадий Васильев, Вы писали:
S>>Давай пример того, как будет записан приведенный мной код на этом гипотетическом фреймворке с использованием boost::bind и boost::function.
S>>Хочется сравнить строгость контроля и синтаксическую целостность.

ГВ>OK, но это не boost::bind, только подобие. Можно, в общем, добиться примерно такого синтаксиса:

ГВ>

ГВ><%=CreateUrl("BeveragesList", urlbind(&Object::method, createObject(), 25));%>
ГВ>

Не понял две вещи:
1. Можно ли использовать методы с другими именами?
2. Что такое createObject()?

ГВ>При условии, что метод объекта выглядит, скажем, так:

ГВ>GeneratedUrl по идее, должен содержать такие методы (возвращать wstring грубо и некультурно, я в курсе

):
Дальнейшее, в принципе, неважно. Как только мы получили объект с информацией об использованных значениях параметров, всё становится легко и приятно. Ну, за исключением того, что в C++ как ни пиши, начинаются какие-то противоестественные мучения с некультурностью определенных типов строк и прочей ерундой, которая во взрослых платформах вообще не привлекает внимания.

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

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

S>>>Давай пример того, как будет записан приведенный мной код на этом гипотетическом фреймворке с использованием boost::bind и boost::function.
S>>>Хочется сравнить строгость контроля и синтаксическую целостность.

ГВ>>OK, но это не boost::bind, только подобие. Можно, в общем, добиться примерно такого синтаксиса:

ГВ>>

ГВ>><%=CreateUrl("BeveragesList", urlbind(&Object::method, createObject(), 25));%>
ГВ>>

S>Не понял две вещи:
S>1. Можно ли использовать методы с другими именами?

Да, разумеется.

S>2. Что такое createObject()?

В данном случае она создаёт экземпляр Object. Можно делегировать создание объекта фреймворку, тогда нужно передать какой-то ключ и вызов будет иметь несколько иной вид, приблизительно такой:

ГВ>>

ГВ>><%=CreateUrl("BeveragesList", urlbind(&Object::method, "InstanceKey", _1, 25));%>
ГВ>>

ГВ>>При условии, что метод объекта выглядит, скажем, так:

ГВ>>GeneratedUrl по идее, должен содержать такие методы (возвращать wstring грубо и некультурно, я в курсе

):
S>Дальнейшее, в принципе, неважно. Как только мы получили объект с информацией об использованных значениях параметров, всё становится легко и приятно. Ну, за исключением того, что в C++ как ни пиши, начинаются какие-то противоестественные мучения с некультурностью определенных типов строк и прочей ерундой, которая во взрослых платформах вообще не привлекает внимания.

Я бы не назвал это мучениями, ничего там протвоестественного нет. Ну да не суть.

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

ГВ>В данном случае она создаёт экземпляр Object. Можно делегировать создание объекта фреймворку, тогда нужно передать какой-то ключ и вызов будет иметь несколько иной вид, приблизительно такой:

ГВ>>>

ГВ>>><%=CreateUrl("BeveragesList", urlbind(&Object::method, "InstanceKey", _1, 25));%>
ГВ>>>

А зачем тебе создавать объект-обработчик, если тебе надо только лишь создать URL (например, для вписания его в HTML)?

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

WF>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>В данном случае она создаёт экземпляр Object. Можно делегировать создание объекта фреймворку, тогда нужно передать какой-то ключ и вызов будет иметь несколько иной вид, приблизительно такой:

ГВ>>>>

ГВ>>>><%=CreateUrl("BeveragesList", urlbind(&Object::method, "InstanceKey", _1, 25));%>
ГВ>>>>

WF>А зачем тебе создавать объект-обработчик, если тебе надо только лишь создать URL (например, для вписания его в HTML)?

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

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

G> Плюс, готовится совершенно потрясающий F# web-фреймворк, с автоматической трансляцией F# в клиентский JavaScript

А что там именно транслироваться будет — исходник на F#, expression tree или IL?

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

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

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

ГВ>>Разумеется, я имею в виду не вызов в прямом смысле этого слова (то есть object->method(parameter); ), а некий аналог boost::bind/boost::function, что-то вроде bind(&Object::method, object, parameter).

AVK>И специфику алгоритма генерации url можно будет менять уже после деплоймента?

Смотря, какая специфика. Кстати, а как это можно сделать средствами MVC?

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

ГВ>Смотря, какая специфика. Кстати, а как это можно сделать средствами MVC?

Поскольку трансляция реально происходит в рантайме, то проблем там никаких.

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

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

WF>>А зачем тебе создавать объект-обработчик, если тебе надо только лишь создать URL (например, для вписания его в HTML)?

ГВ>По идее, чтобы потом к этому объекту можно было обратиться по его "собственному" URL. Если я тебя правильно понял.
Нет. Никакого "собственного" URL у объекта нет. Экземпляр объекта-обработчика будет предоставлен фреймворком при разборе запроса. Рассчитывать на то, что объект, ссылку на который я отдаю в рамках некоторого респонса, доживет до следующего реквеста, в вебе нельзя.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Смотря, какая специфика. Кстати, а как это можно сделать средствами MVC?
Очень просто — поменять, к примеру, конфиг роутинга. Фишка именно в том, что для генерации и парсинга применяется один и тот же набор правил.

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

G>> Плюс, готовится совершенно потрясающий F# web-фреймворк, с автоматической трансляцией F# в клиентский JavaScript

AVK>А что там именно транслироваться будет — исходник на F#, expression tree или IL?

Точно не знаю. Очевидно, не IL. Посмотри.

http://tomasp.net/projects/fswebtools.aspx

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

G>http://tomasp.net/projects/fswebtools.aspx

Там написано, что используется продвинутый фшарповый аналог expression tree. Вобщем, получается эдакий struts с использованием синтаксиса F#.

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

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

ГВ>>Смотря, какая специфика. Кстати, а как это можно сделать средствами MVC?
S>Очень просто — поменять, к примеру, конфиг роутинга.

Например?

S>Фишка именно в том, что для генерации и парсинга применяется один и тот же набор правил.

Ну это как раз достижимо — генерировать URL-ы и парсить их по одним и тем же внешним правилам.

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

WF>>>А зачем тебе создавать объект-обработчик, если тебе надо только лишь создать URL (например, для вписания его в HTML)?

ГВ>>По идее, чтобы потом к этому объекту можно было обратиться по его "собственному" URL. Если я тебя правильно понял.
S>Нет. Никакого "собственного" URL у объекта нет. Экземпляр объекта-обработчика будет предоставлен фреймворком при разборе запроса. Рассчитывать на то, что объект, ссылку на который я отдаю в рамках некоторого респонса, доживет до следующего реквеста, в вебе нельзя.

Согласен, что можно и так поступать: создавать объект только при обращении по соответствующему ему URL (не путать с собственным URL объекта).

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

ГВ>>Смотря, какая специфика. Кстати, а как это можно сделать средствами MVC?
AVK>Поскольку трансляция реально происходит в рантайме, то проблем там никаких.

Трансляция чего во что?

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

ГВ>Например?
Я приводил пример. Когда вместо /beverages/2 используются /search.aspx?category=beverages&page=2

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

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

ГВ>>Например?
S>Я приводил пример. Когда вместо /beverages/2 используются /search.aspx?category=beverages&page=2

Принципиальных препятствий опять таки не вижу. Никто же не заставляет генерировать именно URL в месте обращения на CSP-странице. Можно выталкивать какие-то промежуточные описания. А потом уже настраивать распознаватель.

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

ГВ>Трансляция чего во что?

Написанного тобой выражения в url.

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

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Принципиальных препятствий опять таки не вижу. Никто же не заставляет генерировать именно URL в месте обращения на CSP-странице. Можно выталкивать какие-то промежуточные описания. А потом уже настраивать распознаватель.
Про это я и говорил. Ок, вижу, моих знаний плюсов не хватило. (В скобках докопаюсь всё же до того, что я писал про невозможность воспроизвести функционал на дельфи

. Впрочем, это неважно).

Давайте теперь проверим, у кого лучше диагностика ошибок (ради борьбы с которыми собственно всё и затевалось).

Предположим, у меня есть банальный код:

string s = Url::Helper(&MyController::Search, "Beverages", 2);

Теперь я беру и меняю сигнатуру метода MyController::Search на, скажем, такую:

void MyController::Search(string category, string nameMatch, int page);

Что мне скажет компилятор?

В шарпе компилятор говорит примерно следующее:

No overload for method Search takes 2 arguments

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

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

S>В шарпе компилятор говорит примерно следующее:
S>

S>No overload for method Search takes 2 arguments

C++ будет многословней раза в... В несколько. Но тоже возмутится. Будут ошибки несоответствия ожидаемой и действительной сигнатуры.

Чтобы не быть голословным, скомпилируй у себя вот это:

#include <string>

class X
{
  public:
    void method(int p, std::string v){}
};

class Url
{
public:

template<typename T, typename R, typename P>
static void bind(R (T::*method)(P), const char *, P p){}

template<typename T, typename R, typename P1, typename P2>
static void bind(R (T::*method)(P1, P2), const char *, P1 p1, P2 p2){}

};

void f()
{
  X x;
  Url::bind(&X::method, "abc", 1); // Здесь вызов предполагает сигнатуру void(int), а не void(int, string)
}

Студию можно взять любую, начиная с 2003-й.

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

G>я читал, что на F# можно изобразить "гражданские монады", имеющие эффект монад но при этом не взрывающие мозг.

А в чем отличие "гражданских" монад от военно-полевых?

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

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

G>Плюс, готовится совершенно потрясающий F# web-фреймворк, с автоматической трансляцией F# в клиентский JavaScript и _синхронным_ стилем программирования AJAX-приложений, который эти "монады" задействует.

Вопрос — а зачем транслировать F# в JavaScript, если у нас уже есть .net run-time в браузере в виде silverlight 2.0?

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

Кэр>Вопрос — а зачем транслировать F# в JavaScript, если у нас уже есть .net run-time в браузере в виде silverlight 2.0?

Это они у тру хаскеллистов скопировали

из состава HSP HJavaScript и HJScript.

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

G>>я читал, что на F# можно изобразить "гражданские монады", имеющие эффект монад но при этом не взрывающие мозг.

K>А в чем отличие "гражданских" монад от военно-полевых?

Есть мысль, что они хорошо законспирированны

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

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

На Хаскелле уже есть такой фреймворк — Haskell Server Pages называется и трансляция в клиентский JavaScript там есть.

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

K>>А в чем отличие "гражданских" монад от военно-полевых?
DC>Есть мысль, что они хорошо законспирированны

.

А-а. Монады работают под прикрытием.

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

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

K>А-а. Монады работают под прикрытием.

Тут уже как то кое кто уже демонстрировал, что, в принципе, монады можно найти практически во всем. Ну, типа, как паттерн MVC.

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

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

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

bind, function<>, а так же сахар boost::lambda и т.д.

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

Здравствуйте, vdimas, Вы писали:
V>bind, function<>, а так же сахар boost::lambda и т.д.
Да, мне уже показали. В принципе, оно даже работает, хоть и с несколько менее очевидным error reporting.

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

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

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

G>>http://tomasp.net/projects/fswebtools.aspx

AVK>Там написано, что используется продвинутый фшарповый аналог expression tree. Вобщем, получается эдакий struts с использованием синтаксиса F#.

Там используются:
1) quotations (те же expression tree но шире) для трансляции кода в JS
2) sequences (те же монады, но для простых смертных) для смешанного кода client/server

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

G>>> Плюс, готовится совершенно потрясающий F# web-фреймворк, с автоматической трансляцией F# в клиентский JavaScript
G>http://tomasp.net/projects/fswebtools.aspx

По всей видимости этот проект только концепт,
последняя доступная версия от 1 Марта 2008 собирается самым древним доступным F#.

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

AVK>Тут уже как то кое кто уже демонстрировал, что, в принципе, монады можно найти практически во всем. Ну, типа, как паттерн MVC.

Ну, монада — это всего-навсего пара операций, для которых постулируются несколько аксиом, и нейтральный элемент.
Так что определить что есть монада можно с математической точностью, в отличие от MVC.
Монады могут быть вообще в любом языке, в котором есть ФВП. В некоторых языках они есть в стандарной библиотеке, а в некоторых (в Haskell, C# 3.0, F#) есть синтаксический сахар для них вроде do-нотации Хаскела.
Т.е.

x <- mx

from x in mx // SelectMany - это bind

let! x = mx

Вот пример использования монад из библиотеки F# в C#.

Непонятно, почему монады из F# Gaperton считает "гражданскими". Потому, что они там не позиционируются как что-то мозголомное?

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

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

K>

K>from x in mx // SelectMany - это bind
K>

Почему SelectMany? Это просто Select.

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

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

K>>

K>>from x in mx // SelectMany - это bind
K>>

AVK>Почему SelectMany? Это просто Select.

Ну, если уж на то пошло, это фрагмент кода, который сам по себе не работает, но семантически аналогичен другим двум приведенным фрагментам.
Поэтому комментарий и приведен, что bind — это SelectMany, но не Select. Select — это map.
Для SelectMany все выполняется:

// псевдокод, естественно
// 1) Left Identity
Unit(x).SelectMany(k) == k(x)
// 2) Right Identity
mx.SelectMany(Unit) == mx
// 3) Associative
mx.SelectMany(x => k(x).SelectMany(h)) == mx.SelectMany(k).SelectMany(h)


// где:
IEnumerable<T> Unit<T>(T x)
{
    yield return x;
}
T x;
IEnumerable<T> mx;
IEnumerable<T> k<T>(T x);
IEnumerable<T> h<T>(T h);

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

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	26.10.08 19:54
Оценка:	155 (8) +3

	От:	Cyberax
	Дата:	26.10.08 20:06
	Оценка:	+2 -1

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	26.10.08 22:44
Оценка:	+1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	26.10.08 23:01
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	26.10.08 23:32
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	27.10.08 06:06
Оценка:	62 (10) +5

	От:	Воронков Василий
	Дата:	27.10.08 13:05
	Оценка:

От:	Гест	https://zverok.github.io
Дата:	02.11.08 21:41
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	14.11.08 07:23
Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	14.11.08 09:27
Оценка:	+2

От:	dr.Chaos	Украшения HandMade
Дата:	26.11.08 15:13
Оценка:

От:	achmed	https://www.linkedin.com/in/nail-achmedzhanov-9907188/
Дата:	27.11.08 13:53
Оценка:

	От:	kkolyan
	Дата:	15.11.08 08:49
	Оценка:

	От:	WFrag
	Дата:	15.11.08 09:25
	Оценка: