Здравствуйте, AndrewVK, Вы писали:
AVK>Фидбек может и забит, но я пока ни с одним багом компилятора не столкнулся.
Ну, так пойди почитай фидбэк. А то я вот уже не раз сталкивался.
VD>> А внешний мир к дотнету отношения не имеет.
AVK>Агащасблин. И БД сервера это миф. И сеть никому не нужна. И интероп придумали враги. А уж СОМ, так его точно нет, это ж фантастика.
Ни, что из перечисленного во втором фрэймворке не изменилось.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
AVK>>Агащасблин. И БД сервера это миф. И сеть никому не нужна. И интероп придумали враги. А уж СОМ, так его точно нет, это ж фантастика.
VD>Ни, что из перечисленного во втором фрэймворке не изменилось.
ADO.NET изменился, именно с ним мы поймали 2 баги. В интеропе много изменений. В СОМ-интеропе были проблемы, пришлось код править. Одно из изменений — теперь, при публикации .NET класса публикуются все его базовые типы. У нас базовые типы были не ComVisible — получили глюки и исключения. Кое что изменилось в XsltTransform, пришлось править некоторые шаблоны. Была еще куча мелких проблем, всего не упомнишь.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>ADO.NET изменился, именно с ним мы поймали 2 баги. В интеропе много изменений. В СОМ-интеропе были проблемы, пришлось код править.
Думаю, что вы просто нали свои старые ошибки. Фрэймворк обратно совместим.
AVK> Одно из изменений — теперь, при публикации .NET класса публикуются все его базовые типы. У нас базовые типы были не ComVisible — получили глюки и исключения.
За публикацию в КОМ-е классов, а не интерфейсов нужно вообще было тому кто этим занимался шею намылить.
В общем, если бы пробовали перейти еще на бэттах, то к релизу проблем бы не осталось. Все именно от того, что начали заниматься проблемой слишком поздно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
AVK>>ADO.NET изменился, именно с ним мы поймали 2 баги. В интеропе много изменений. В СОМ-интеропе были проблемы, пришлось код править.
VD>Думаю, что вы просто нали свои старые ошибки. Фрэймворк обратно совместим.
Обе баги признаны МС. Для первой уже выпущен хотфикс.
AVK>> Одно из изменений — теперь, при публикации .NET класса публикуются все его базовые типы. У нас базовые типы были не ComVisible — получили глюки и исключения.
VD>За публикацию в КОМ-е классов, а не интерфейсов нужно вообще было тому кто этим занимался шею намылить.
Это требование студии.
VD>В общем, если бы пробовали перейти еще на бэттах, то к релизу проблем бы не осталось. Все именно от того, что начали заниматься проблемой слишком поздно.
Какая разница когда время терять? Что с бетами, что с релизом. Только с бетами ты геморой почуствовал даже на своем R#. А на реальном проекте мы бы просто зашились по билдам скакать.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
AVK>>Я в списке Open projects его не обнаружил. Из относящегося к нему я заметил только комплит.
VD>А что кроме комплита еще делается?
Плагин к студии.
VD>Он и делается.
Нет. В репозитории лежат исходники пакета.
VD> И делается как часть основного проекта. А сам проект открытый. Исходники все доступны.
Я имел ввиду не то, что исходники доступны, а то, что его мог бы править кто то кроме них самих. Ты думаешь почему там *.cs? Потому что ребята явно ни разу этого не делали и пользуются семплами и вспомогательным кодом от МС, который, разумеется, на шарпе. Только вот МС, мерзавцы, не предоставили стандартную реализацию проекта, поэтому они там зашьются с пакетом ковыряться, особенно по неопытности.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, IT, Вы писали:
IT>Тем не менее, не смотря на все эти A, B и C ты продолжаешь писать на C++ и всячески его защищать. Значит это не такая уж и большая проблема
Продолжаю писать потому, что много чего на C++ сделано и проще продолжать писать на C++, чем переходить на что-то другое.
Защищаю потому, что заинтересован в его существовании и привлечении в C++ новых толковых людей (диктуется предыдущим пунктом). А так же тем, что наезды на C++ какие-то... оголтелые, что ли.
И, кстати, подходила бы для моих задач производительность Ruby, перешел бы на Ruby.
А про проблему с макросами я говорю потому, что мне кажется, что Nemerle ее повторяет. И когда тут утверждают, что в Nemerle все классно и даже макросы гигиенические (это же нужно было такой термин придумать, видимо не знает человек, куда гигиенические средства засовывают), то мне кажется, что в общем восторге от Nemerle намерено не замечается большая проблема языка.
В C/C++, как я уже говорил, тяжесть этой проблемы снижена за счет дисциплины и соглашения об именовании макросов. Но и в C/C++ макросы -- это детские игрушки по сравнению с макросами Nemerle.
Вообще утомило меня слово Nemerle в последнее время. Как Сергей Губанов для многих сделал антирекламу Оберона и Вирта, так здесь для меня сделали антирекламу Nemerle. Нужно взять тайм-аут на годик. Глядишь, вопрос сам собой и проясниться.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
E>>Сборку с реализацией макросов или сборку в которой макросы используются?
VD>Пишешь сборку с макросами. А используешь в прикладной. Чтобы прикладная сборка могла использовать мкросы при ее компиляции нужно подключить сборку с макросами и в файле где хочешь испльзовать макрос из этой сборки указать пространство имен в ктором объявлен макрос.
Здесь что всеобщий тупизм происходит?
Я спрашиваю, что будет если в прикладной сборке, в одном файле, в одной области видимости, мне потребуется использовать два изменяющих синтаксис макроса из разных сборок, но эти макросы конфликтуют между собой? Писал эти макросы не я. Более того, на ранних версиях эти макросы могли быть совместимы, при выходе следующей версии совместимость могла быть потеряна, т.к. их разрабатывают разные команды, ничего друг о друге не знающие.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, eao197, Вы писали:
IT>>Тем не менее, не смотря на все эти A, B и C ты продолжаешь писать на C++ и всячески его защищать. Значит это не такая уж и большая проблема
E>Продолжаю писать потому, что много чего на C++ сделано и проще продолжать писать на C++, чем переходить на что-то другое.
Много чего сделано не только на C++, но я тебя понимаю. Действительно проще продолжать писать на том, что хорошо знаешь и к чему привык.
E>Защищаю потому, что заинтересован в его существовании и привлечении в C++ новых толковых людей (диктуется предыдущим пунктом). А так же тем, что наезды на C++ какие-то... оголтелые, что ли.
Оголтелый означает несдержанный, низкий, крикливый. Ты наверное хотел сказать безосновательный?
C++, точнее даже не сам язык, а комитет, отвечающий за его развитие, критикуют за неповоротливость и медлительность. 15 лет назад C++ был суперсовременным языком, что позволило ему прочно войти в ряды мейстримов. Но сегодня этот язык безнадёжно устарел. Почему-то такие простые и полезные вещи как интерфейсы и свойства ну никак в него не вписываются, рефекшин и GC с ним полностью несовместимы, а развитие происходит в основном в сторону культивирования побочных эффектов компилятора.
E>И, кстати, подходила бы для моих задач производительность Ruby, перешел бы на Ruby.
И это я понимаю. Как было сказано выше действительно проще продолжать писать на том, что хорошо знаешь и к чему привык.
E>А про проблему с макросами я говорю потому, что мне кажется, что Nemerle ее повторяет.
Тут уже не раз было сказано, что макросы C/C++ и макросы Nemerle объединяет только лишь название, и за это название макросы Nemerle можно действительно покритиковать. Больше между ними нет ничего общего. Макросы C — это примитивная текстовая постановка, которая выполняется даже не самим компилятором, а препроцессором. Макросы Nemerle — это управление compile-time генерацией кода, которая не опаснее всё более и более широко применяемого эмита в .NET, но лишена большинства его недостатков.
E>И когда тут утверждают, что в Nemerle все классно и даже макросы гигиенические (это же нужно было такой термин придумать, видимо не знает человек, куда гигиенические средства засовывают), то мне кажется, что в общем восторге от Nemerle намерено не замечается большая проблема языка.
Проблемы в языке, которые вы с AVK пытаетесь найти — это поиски чёрной кошки в тёмной комнате, которой там нет. Это всё смешно и несерьёзно. Compile-time генерация кода — это как раз то, чего сейчас так не хватает мейстримовым языкам. Надеюсь преимущества compile-time генерации перед run-time генерацией кода очевидны и их не надо объяснять. А run-time генерация сейчас используется всё шире (даже тем же AVK), т.к. это верный способ добиться максимального уровня декларативности и возложить основную часть работы на генератор, который множество раз сделает всё так, как один раз в него заложил разработчик.
E>В C/C++, как я уже говорил, тяжесть этой проблемы снижена за счет дисциплины и соглашения об именовании макросов. Но и в C/C++ макросы -- это детские игрушки по сравнению с макросами Nemerle.
Игрушки — это точно, только с другим знаком. Твоя проблема с main (описываемая тобой несколькими постами выше) просто не может случится в Nemerle. Даже в C++ она надумана. Во-первых, тому кто додумался до такого бреда место на http://www.thedailywtf.com/. А во-вторых, достаточно одной строчки #undef после #include чтобы эту проблему решить. В Nemerle же такая ситуация может случится только если ты этого захочешь сам. В общем, ваши с AVK аргументы пока высосаны из пальца и на серьёзное исследование проблем языка не тянут. Боюсь, что они больше рассчитаны на публику, но даже в этом пока не нашли поддержки.
E>Вообще утомило меня слово Nemerle в последнее время. Как Сергей Губанов для многих сделал антирекламу Оберона и Вирта, так здесь для меня сделали антирекламу Nemerle. Нужно взять тайм-аут на годик. Глядишь, вопрос сам собой и проясниться.
Аналогия не верна. Умозаключения СГ больше основаны на фанатизме. Умозаключения поклонников Nemerle (в том числе и мои) — на практицизме.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>Да ну. Это довольно извращенческий подход — сделать комплит на языке с комплитом, чтобы потом используя этот комплит переписать сделанное на более мощьном языке.
А где там комплит? Чего-то его не вижу..
A>>Судя по истории они только 12-го начали VD> Вряд ли. Слишком много наколбасили.
Да и наколбасили совсем немного
самый большой файл — TokenProcessor.cs — 13.1 кб
остальные 10 и меньше, и самих файлов мало
... << RSDN@Home 1.2.0 alpha rev. 634>>
Не переходите улицу на тот свет..
Re[17]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, eao197, Вы писали:
VD>>Пишешь сборку с макросами. А используешь в прикладной. Чтобы прикладная сборка могла использовать мкросы при ее компиляции нужно подключить сборку с макросами и в файле где хочешь испльзовать макрос из этой сборки указать пространство имен в ктором объявлен макрос.
E>Здесь что всеобщий тупизм происходит?
Ответить на этот вопрос я могу таким красным модераторскым предупреждением. Например,
Бан на 300 лет за неуставные отношения в особо крупных размерах.
E>Я спрашиваю, что будет если в прикладной сборке, в одном файле, в одной области видимости, мне потребуется использовать два изменяющих синтаксис макроса из разных сборок, но эти макросы конфликтуют между собой? Писал эти макросы не я. Более того, на ранних версиях эти макросы могли быть совместимы, при выходе следующей версии совместимость могла быть потеряна, т.к. их разрабатывают разные команды, ничего друг о друге не знающие.
Ты и сам знаешь ответ на этот вопрос. Это будет означать, что тебе крупно не повезло и надо выбросить одну из используемых библиотек. А лучше обе. Та же проблема существует и в других языках. В более современных она решается явным указанием пространства имён. В устаревших не решается никак.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, IT, Вы писали:
E>>Защищаю потому, что заинтересован в его существовании и привлечении в C++ новых толковых людей (диктуется предыдущим пунктом). А так же тем, что наезды на C++ какие-то... оголтелые, что ли.
IT>Оголтелый означает несдержанный, низкий, крикливый. Ты наверное хотел сказать безосновательный?
Нет, осований для критики C++ более чем достаточно. Просто сейчас, имхо, слишком часто критикой C++ занимаются те, что либо ушел с C++ на другой язык, либо собирается. И выглядит это не красиво.
IT>Игрушки — это точно, только с другим знаком. Твоя проблема с main (описываемая тобой несколькими постами выше) просто не может случится в Nemerle. Даже в C++ она надумана. Во-первых, тому кто додумался до такого бреда место на http://www.thedailywtf.com/. А во-вторых, достаточно одной строчки #undef после #include чтобы эту проблему решить.
Не решилась. Я пробовал. Слишком многими путями этот злополучный ace/OS_main.h в прикладной код подключался (не напрямую).
Оказалось гораздо проще сменить имя пространства имен.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, IT, Вы писали:
IT>Ты и сам знаешь ответ на этот вопрос. Это будет означать, что тебе крупно не повезло и надо выбросить одну из используемых библиотек. А лучше обе. Та же проблема существует и в других языках. В более современных она решается явным указанием пространства имён. В устаревших не решается никак.
В C++ такой проблемы в таких масштабах просто не существует. А правила использования макросов регламентируются хотя бы соглашениями об именовании и постоянными напоминаниями, что макросы -- это зло. В Ruby такой проблемы нет в принципе (в Python, насколько понимаю, так же). В Java ее так же нет. В C#, если не ошибаюсь, нет.
Зато в Nemerle, вокруг которого раздувается шумиха, есть.
И решение классное -- выбросить библиотеки. А на что их заменять, если за них было уплочено? И если заменять их не на что?
В общем, цель всего этого дела была понят для себя, возможны ли подобные проблемы в Nemerle. Оказалось, что возможны. Все, вопросов больше не имею.
Только впечатление осталось: в C++ есть указатели. Со всеми вытекающими последствиями. Хотя у многих программистов с указателями проблем нет. Но C++ за указатели ругают. Имхо, если заменить C++ на Nemerle, а 'указатели' на 'макросы', то получится вполне точно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>3. MS купит команду Nemerle и конкуренция будут происходить в самой MS.
А кому принадлежат права на разработки в рамках MS Research?
Если MS, то и покупать ничего не надо http://research.microsoft.com/programs/europe/rotor/2004Projects.aspx
Хотя может MS просто им денег дала, а права у них же и остаются.
... << RSDN@Home 1.2.0 alpha rev. 634>>
Не переходите улицу на тот свет..
Re[21]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, AndrewVK, Вы писали:
VD>>А что кроме комплита еще делается? AVK>Плагин к студии.
Это все равно, что ничего не сказать.
VD>>Он и делается.
AVK>Нет. В репозитории лежат исходники пакета.
Ну, а пакет то что делает?
VD>> И делается как часть основного проекта. А сам проект открытый. Исходники все доступны.
AVK>Я имел ввиду не то, что исходники доступны, а то, что его мог бы править кто то кроме них самих.
Ты вот это http://nemerle.org/Open_projects читал?
AVK> Ты думаешь почему там *.cs? Потому что ребята явно ни разу этого не делали и пользуются семплами и вспомогательным кодом от МС, который, разумеется, на шарпе.
Дык у них конвертер с Шарпа есть. Правда основан он на кривом парсере взятом с АНТЛР-овского сайта. Но процентов 85 кода он конвретирует.
Будет время сделаю полноценный конвертер на базе моего парсера.
AVK> Только вот МС, мерзавцы, не предоставили стандартную реализацию проекта, поэтому они там зашьются с пакетом ковыряться, особенно по неопытности.
Недеюсь найдутся добрые и знающие люди которые им помогут. По крайней мере на сегодня я бы оценил востребованность комплита как наиболее важную вещь. Сцинтила для больших проктов не пригодна.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, AndrewVK, Вы писали:
AVK>Обе баги признаны МС. Для первой уже выпущен хотфикс.
Ладно. Без разницы какие там у вас были трудности с переходом на другую версию фрэймтворка.
Главное, что этот опыт не имеет никакого отношения с испльзованием другого языка.
Ты ведь не будель переводить на другой язык имеющийся код? Фрэймворк будет тот же.
AVK>Какая разница когда время терять? Что с бетами, что с релизом. Только с бетами ты геморой почуствовал даже на своем R#. А на реальном проекте мы бы просто зашились по билдам скакать.
Тут ты не прав. Если бы вы пробовали перейти еще на бэтах. То к релизу большинства проблем просто не было бы. И вы бы не сделали кучи ошибок, так как уже знали бы о проблемах.
Ладно, не важно это все.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
Вряд ли. Слишком много наколбасили.