VladD2 пишет:
> Здравствуйте, Andrei N.Sobchuck, Вы писали:
> ANS>VladD2 пишет:
>> > C>чем только можно. Лучше бы создателям С# это понять, а не пытаться
>> > C>адаптировать систему типов под SQL, XML и т.п.
>> >
>> > Не боись. Они явно не тупее нас с тобой.
>
> ANS>Кстати, вот в треде об обучении я видел высказывание, что зачем учить
> ANS>другие языки, один выучил, что самый на рынке популярный и вперёд.
>
> Кстати, ты не первый кто их видел. Будь бобр, приведи ссылку на такое
> высказывание. Только чтобы там именно было "зачем учить другие языки". А
> таких как ты уж больно много стало. Замечаете то что хотите, а не то что
> есть на самом деле.

Хочеш <br />
дословно &mdash; вот тебе дословно

Автор: Dog
Дата: 10.03.05

:
A>Следующей по важности целью является обучение студента
алгоритмированию. Эта цель определяется специальностью, на которую
учащийся поступил. Тут, очевидно, язык не важен, практически полная
абстракция. Единственное требование — это соответствие возможностей
языка поставленным задачам. Пишите хоть на языке, который называется
"великий и могучий Русский язык", только вот компилятора для него еще не
придумали и тестировать написанную программу вручную преподу врядли
понравится.
Если язык не важен, то почему нельзя писать, на том с чем он столкнётся?
Зачем для этого учить лишние языки (фортраны, паскали) Не проще ли на
основе применения этих алгоритмов заодно углубить свои познания в том же
C# или Java?

> ANS> В
> ANS>связи с этим возник вопрос, а кто тогда разрабатывает новые платформы,
> ANS>языки, системы? Откуда они берутся?
>
> Задай это тому от кого ты это слышал.

Задать вопрос тому, от кого я слышал о появлении новых платформ? Да ты
шутник!

> ANS>Это действительно совсем ни у кого из ныне учищахся нет куража от того,
> ANS>что разобрался *сам* как работает система, и сделал по-другому?
> ANS>Может лучше, может хуже, но сделал *сам*. Или просто такие люди
> ANS>сюда не пишут, а тихонько себе что-то хачут?
>
> Однако много вопросов можно задать если приписать собеседнику слова
> которых он не говорил...

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

--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.

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


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

И очень даже сбыточная Эпловую Cocoa видел? Мне очень нравится!
И гибкость, и MVC-везде, где только можно, и вместе с тем, простая для изучения и работы...
У нее, правда, есть один фатальный недостаток...

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

C>Возьмем этот же пример: "_arg1++ + _arg2". Операция _arg1++ генерирует
C>функтор, принимающий на вход первый аргумент и увеличивающий его на 1.
C>_arg2 — это функтор, который ничего не делает. Далее идет операция "+",
C>которая создает третий функтор, принимающий на вход два других функтора.
C>Это сложно рассказывать — надо показывать.

Что ты называшь "фанторами"? Что же до показывать. Я тебе привожу примеры которые можно легко откомпилировать просто поместив в пустой проект. Твой же код воообще не полно и требует установки дополнительных библиотек и настройки среды. Так что с показом тут не очень.

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

C>Так тут абсолютно тоже самое. _arg++ — функция, _arg2 — функция, а +
C>комбинирует две функции.

Нет в твоем коде ни одной функции. Еще раз повторюсь. Я привел полностью рабочий, а не гипотетический. В общем, не нужно оптимизировать. Просто повтори. И целиком, а не частично.

>>static IEnumerable<int> XRange(int start, int len, int inc)
>>{
>> int count = (len — start) / inc;
>> for (int val = start, i = 0; i < count; i++, val += inc)
>> yield return val;
>>}
>>
>> и сравни с оригиналом.

C>http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
C>

C>int XRange(ccrContParam,int start,int len,int inc)
C>{
C>    ccrBeginContext;
C>    int i,count,val;
C>    ccrEndContext(foo);

C>    ccrBegin(foo);
C>    count=(len-start)/inc;
C>    for (foo->i=0,foo->val=start; foo->i<count; foo->i++,foo->val+=inc)
C>    {
C>        ccrReturn(foo->val);
C>    }
C>    ccrFinish(-1);
C>}
C>

C>Что характерно, если развернуть макросы и сравнить со сгенерированным
C>кодом для C#, то получится примерно одно и то же.

Да? Вот беда. Мой код компилируется и работает. А твой даже не очень. При этом он уже больше моего. И вообще не ясно что он делает. А что там делает компилятор меня не интересует. Я работаю на уровне абстракций языка. И получаю ясную и простую программу.

C>Массивы на С++ настолько гибкие, что без ограничителей с ними сложно
C>работать

Ага. Я бы сказал больше. В С++ просто нет полноценных массивов.

C>А для массива с фиксированной длиной есть еще и boost::array.

Это опять же обертка. Массивы — это примитивы языка.

>> Вот так по капле и получается трах на ровном месте. Я тут как-то делал
>> программку — подсчет слов, на С++ и на Шарпе. На Шарпе сделал за 2
>> минуты. На С++ протрахался час.

C>Это не показатель. Может быть я тоже самое написал бы за 5 минут.

Уверен, что если задача не пишется "по памяти", т.е. второй раз, то ты всегда проиграешь мне минимум в трое. Ну, а на сложных и того больше. Уроветь языка очень низкий. Количество шолухи которое постоянно нужно держать в голове слишком велико. Надежность получаемых решений низкая. Библиотеки сложные и запутанные. В итоге постоянно возникают затыки на ровных местах. Я когда-то тоже думал что пишу на плюсах относительно быстро. Вот только ключевое слово оказалось "относительно".

C>Согласен, реализация Свинга хромает (хотя последние версии очень даже
C>нормальны).

Возможно я не копался в последнем. Но все что я видел оказывлось красивым до тех пор пока сам не начинаещь использовать получившийся ГУИ. А как начинашь, так сразу нарывашся на кучу мелких проблем. То клипборд работает не так как надо, то функциональности не хватет. То с фокусом проблемы.

C>У меня просто это такая несбыточная мечта, что кто-нибудь
C>наконец-то создаст нормальный GUI-фрэймворк.

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

>> C>3. СЛИШКОМ сильное использование наследования.
>> Ага. Это точно. А так же полиморфизма и инкапсуляции. Железные
>> недостатки.

C>Hint: кроме наследования есть еще и делегирование и аггрегирование.

Наследование само по себе быть недостатком не может. Вернее может, но только если в голове тараканы. Другое дело, что наследование может быть не оптимальным. Но что-то я не припомню особых проблем с этим в Формсах.

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


ANS>Хочеш <br />
<span class='lineQuote level1'>ANS&gt;дословно &mdash; вот тебе дословно</span>

Автор: Dog
Дата: 10.03.05

:
ANS>A>Следующей по важности целью является обучение студента
ANS>алгоритмированию. Эта цель определяется специальностью, на которую
ANS>учащийся поступил. Тут, очевидно, язык не важен, практически полная
ANS>абстракция. Единственное требование — это соответствие возможностей
ANS>языка поставленным задачам. Пишите хоть на языке, который называется
ANS>"великий и могучий Русский язык", только вот компилятора для него еще не
ANS>придумали и тестировать написанную программу вручную преподу врядли
ANS>понравится.
ANS>Если язык не важен, то почему нельзя писать, на том с чем он столкнётся?
ANS>Зачем для этого учить лишние языки (фортраны, паскали) Не проще ли на
ANS>основе применения этих алгоритмов заодно углубить свои познания в том же
ANS>C# или Java?

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

Можно переспросить у товарища что он имел в виду.

>> ANS> В
>> ANS>связи с этим возник вопрос, а кто тогда разрабатывает новые платформы,
>> ANS>языки, системы? Откуда они берутся?
>>
>> Задай это тому от кого ты это слышал.

ANS>Задать вопрос тому, от кого я слышал о появлении новых платформ? Да ты
ANS>шутник!

Тому от кого ты слышал, что учить нужно только один язык.

ANS>А ты не ёрничая ответил бы есть у тебя кураж когда ты, например, пишеш
ANS>Janus, или разбираешся в чем или нет?

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

Вот недавно перевел Янус на 64-битную платформу. Веренее сам Янус перевелся влет и так. А вот нэйтив-код (Синтила (текстовый редаткор) и т.п.) оказалось перевести не так просто. Потрахался не не шутку с С++. Но тоже интересно.

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

>> C>Новая шутка: стандартный синтаксис SQL. Запомню.
>> Да, уж. Потрудись: http://aam.ugpl.de/book/print/157 .

C>Ну и? А теперь вы можете мне показать распространенную крупную базу, у
C>которой нет своих несовместимых со стандартом расширения SQL?

Не моежм. Но это и не требуется, так как мы можем лицизреть целую кучу СУБД удовляетворяющих SQL-92/99. Тот же MSSQL и Oracle на сегодня ему точно удовлетворяют. Вполне достаточно если будет совместимость с SQL-92.

C>Если для этого надо вводить новые сущности в язык ДЛЯ КАЖДОГО ОТДЕЛЬНОГО
C>СЛУЧАЯ — то это лучше не делать вообще.

Согласен. Думаю, разработчики Шарпа тоже согласятся. Вот только "ДЛЯ КАЖДОГО ОТДЕЛЬНОГО СЛУЧАЯ" — это явно твои домыслы.

C>Правда, полностью его нормально никто не сделал.

Там делать нечего. МС повторил стандарт DCE RPC.

C>Угу. Сейчас как раз этим и занимаюсь, блин. Пишу свою реалиазцию контейнера.

Велосипедостроение увлекательное занятие.

VladD2 пишет:

> C>Ну и? А теперь вы можете мне показать распространенную крупную базу, у
> C>которой нет своих несовместимых со стандартом расширения SQL?
> Не моежм. Но это и не требуется, так как мы можем лицизреть целую кучу
> СУБД удовляетворяющих SQL-92/99. Тот же MSSQL и Oracle на сегодня ему
> точно удовлетворяют. Вполне достаточно если будет совместимость с SQL-92.

Тогда нельзя будет использовать расширеные возможности каждой БД. Но не
стоит волноваться — для МS SQL поддержка всех его расширенных
возможностей по какой-то совершенно странной случайности обязательно будет.

> C>Если для этого надо вводить новые сущности в язык ДЛЯ КАЖДОГО
> ОТДЕЛЬНОГО
> C>СЛУЧАЯ — то это лучше не делать вообще.
> Согласен. Думаю, разработчики Шарпа тоже согласятся. Вот только "ДЛЯ
> КАЖДОГО ОТДЕЛЬНОГО СЛУЧАЯ" — это явно твои домыслы.

SQL и XML — для меня частные случаи.

> C>Правда, полностью его нормально никто не сделал.
> Там делать нечего. МС повторил стандарт DCE RPC.

Поищите в MSDN по словам "wire_marshal" — это МСовское расширение RPC.
Там еще таких несколько есть.

> C>Угу. Сейчас как раз этим и занимаюсь, блин. Пишу свою реалиазцию
> контейнера.
> Велосипедостроение увлекательное занятие.

Я не с ноля же пишу, а аккуратно копирую с ATL

--
С уважением,
Alex Besogonov (alexy@izh.com)

_wqwa пишет:

> C>Согласен, реализация Свинга хромает (хотя последние версии очень даже
> C>нормальны). У меня просто это такая несбыточная мечта, что кто-нибудь
> C>наконец-то создаст нормальный GUI-фрэймворк.
> И очень даже сбыточная Эпловую Cocoa видел? Мне очень нравится!

Я вообще на OS X смотрю и плачу. Все в ней сделано правильно (по
сравнению с Win/Lin), а вот использовать — нельзя Так как уровень
распространения Маков ~0.

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 пишет:
> C>Ну и? А теперь вы можете мне показать распространенную крупную базу, у
> C>которой нет своих несовместимых со стандартом расширения SQL?
>
> Не моежм. Но это и не требуется, так как мы можем лицизреть целую кучу
> СУБД удовляетворяющих SQL-92/99. Тот же MSSQL и Oracle на сегодня ему
> точно удовлетворяют. Вполне достаточно если будет совместимость с SQL-92.

Можно ссылку хотя бы на то, где написано, что MSSQL полностью
удовлетворяет SQL-92.

--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.

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

ANS>Можно ссылку хотя бы на то, где написано, что MSSQL полностью
ANS>удовлетворяет SQL-92.

Несомненно. И не одну.

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

ANS>Можно ссылку хотя бы на то, где написано, что MSSQL полностью
ANS>удовлетворяет SQL-92.
Полностью не удовлетворяет никто, но "удовлетворяемость" стандарту делится на несколько уровней: начальный, переходный, промежуточный, полный... Официально все СУБД сертифицированы только на начальный, в том числе и MSSQL, а неофициально основные игроки поддерживают где-то на уровне переходный-промежуточный.

VladD2 пишет:
> ANS>Можно ссылку хотя бы на то, где написано, что MSSQL полностью
> ANS>удовлетворяет SQL-92.
>
> Несомненно. И не одну
> <http://www.google.ru/search?hl=ru&amp;q=SQL-92+MS+SQL+Server&amp;lr=&gt;.

Я вот
набрал
и в первой <br />
же ссылке вижу:
Both SQL Server 2000 and MySQL version 4.1 support the ANSI SQL-92
entry level and do not support the ANSI SQL-92 intermediate level.

--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.

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

ANS>Both SQL Server 2000 and MySQL version 4.1 support the ANSI SQL-92
ANS>entry level and do not support the ANSI SQL-92 intermediate level.

И? "support the ANSI SQL-92 entry level" более чем достаточно. Почитай что это означает. Это как раз совместимость на уровне селектов и апдэйктов.

_FRED_ пишет:

>>>>> И что это даст? Они и в виде классов вписываются в концепции языка
>>>>> очень хорошо.
>>> C>Ну так и SQL тоже.
>>> В SQL синтаксис есть, например, который компилятор проверить может.
> C>А в 3D компилятор мне не сможет проверить, что у меня матрица не
> C>сингулярная.
> Гы. Приходится описывать килограммы константных матриц?? Я дел с
> графикой не имел, так что поправь пожалуйста, если я ошибаюсь.

Нет, не приходится. Но мне неприходится описывать и килограммы
статического SQL! Он у меня лежит в отдельном XML-файле, в котором
описывается OR-maping.

> Приведи примерчик кода, в котором компилятор "3D компилятор мне ...
> сможет проверить, что у меня матрица не сингулярная".

Matrix m1(....);
Vector vect=pos*mi.invert();

> C>В графике есть, например, языки шейдеров.
> не оно? http://microsoft.cs.msu.su/projects/ilshaders/

Оно.

>>> . А если Firebird при этом только сообщает об ошибке, то это
>>> равнозначно и ошибке в рантайме.
> C>Вот. Как выяснилось компилятор у нас уже не все проверяет. А если
> C>подумать, то можно накопать и еще таких камешков подводных.
> Насколько часто из программы надо-то константные выражения вставлять в
> таблицу???? В рантайме-то компилятор мало чем помочь может.

ВОТ! А зачем тогда вообще нужна вся эта возня с SQL в языке? Сложность
языка увеличивается пропорционально квадрату количества фич в нем. Зачем
сильно усложнять язык, если можно обойтись без этого?

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

Ну так используйте OR-maping, и пусть архитектор базы меняет его при
изменении схемы. Какие здесь проблемы?

>>> Что именно в этом "странно"?
> C>Что для компиляции требуется DB-specific модули.
> "Что именно в этом "странно"?" Я так и не вижу ничего "этакого"...

Я понимаю, людям которые пишут все только под одну конфигурацию софта
(Win+MS SQL+.NET) это не кажется странным...

> C>А проверки типов из такого никуда не уйдут — они просто спрячутся. А
> для
> C>ORM обычно есть инструменты, которые позволяют провалидировать maping
> C>относительно данной БД.
> Проверки типов будут происходить в компаил-тайм, а не в рантайме (я
> надеюсь ). Разница есть?

Кто мешает вставить в билд-скрипт валидацию текущего OR-mapping'а
относительно текущей схемы БД? И будет та же compile-time проверка.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Ухх, только сейчас заметил это письмо.

VladD2 пишет:

> C> то лучше уж пусть не
> C>проверяет вообще. Сейчас такая ситуация, что у каждой СУБД куча своих
> C>заморочек — и если сделать что-то общее для всех СУБД, то получится
> C>весьма ограниченная функциональность.
> Зачем низная ничего о реализации делать предположения? Пусть делают.
> Сделают — скажем спасибо. Не сделают, значит и вправду слишком сложно
> и не универсально получилось.

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

> C>Даже за бабки нет ничего нормального (мы искали, причем взяли бы за
> C>почти любую цену).
> Вы плохо искали. Есть несколько реализаций. В том числе тут рядом
> обсуждался один из вариантов. Там не только КОМ, но и АТЛ с МФЦ дают.
> А классика есть у CA.

Можно ссылки?

> C>Пальцем в небо — OLE я знаю досконально.
> Я плякаль. Досканальное знание ОЛЕ и при этом не знает, что IDispatch
> появился в VB значительно позже ОЛЕ. ОЛЕ 1 даже на КОМ не было
> основано. КОМ собственно и родился как побочный продукт разработки ОЛЕ.

Я говорю сейчас об OLE 1? Под словом "OLE" обычно понимают OLE 2.

> C> Сейчас вот как раз дописываю
> C>ActiveX-контейнер из ATL
> Рад за тебя. Я такой фигней бросил заниматся еще в 2001. Можешь взять
> готовый <http://www.optim.ru/Software/rus/ascContainer/asccontainer.asp&gt;.

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

> C>OLE зависим от IDispatch'а, это ключевая фишка для ActiveX-контролов.
> Знаток, блин. ActiveX-ы появились лет эдак через 10 после появления
> ОЛЕ 1 и через где-то 5 после ОЛЕ2.

Про OLE 1 забудем, оно к делу слабо относится. Чистый COM появился в
начале 90-х, у меня сейчас лежит драфт стандарта MAPI от 91 года — там
уже используется COM.

> Они базировались на ОЛЕ. По началу они так и назывались OLE Control
> eXtention, или OCX.

Сначала был крайне успешный VBX, который просто позволял подключать к VB
внешние обработчики виндовых событий.

> IDispatch же появился в VB (если не ошибаюсь 3 или 4) когда в нем
> технология VBX была заменана на OCX. На сегодня дисптч относят к
> Automation API. В начале его назвали OLE Automation API, но потом
> переименовали, так как мода называть все "ОЛЕ" закончилась и началась
> мода "+" и "Active".

Да, и именно тогда началась настоящая мода на ActiveXы, хотя OCX до
этого был практически незаметен (еще и потому, что не было нормальных СДК).

> C>теории возможны AX-контролы и без IDispatch'а, но на практике они будут
> C>малополезны, так как их свойства нельзя будет редактировать из
> VB/Delphi/...
> Очень смешно слышать пдобное от досканального знатака ОЛЕ. Оле и
> расшифровывалось как Обжект Линкинг этд Эмбединг.

Прекрасно знаю. Однако ActiveX — это часть OLE, и я вроде бы говорил,
что не разделяю их.

> Изначально это интерфейс для связывания Ворда с Экселем (чтобы в Ворд
> можно было вставлять табличку из Экселя). Ну, и нет никаких проблем
> создать ActiveХ который будет использовать исключительно
> кастом-интерфейсы и прекрасно работать в ВБ (и уж темблее в Дельфи).

Да, но какая _практическая_ польза будет от него? Его свойства нельзя
будет редактировать визуально из VB/Delphi, а это и есть главное
достоинство AXов.

> Ну, и главно. Ты занимашся технологиями прошлого века. Тот же винформс
> даст им 100-кртаную фору.

Для C# нет нормальной поддержки VBA. Был VSA, но МС его перестал продавать.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Да, но какая _практическая_ польза будет от него? Его свойства нельзя
C>будет редактировать визуально из VB/Delphi, а это и есть главное
C>достоинство AXов.

Заходишь в VS... создашь проект "ATL Project"... Выбирашь добавит класс... Выбирашь "ATL Control"... В диалоге содания на закладке "Options" выбирашь "Interface: Custom"... Добавляешь свойство... Идешь в Дельфи, VS (хоть в дотнет) или ВБ6 и видшь что все ОК.

Далее думашь за каких хреном создал это доисторическое убожщен так как и новый ВБ и Шарп прекрасно живут с ВыньФормсовыми контролами которые и создавать и поддерживать в сто раз проще.

>> Ну, и главно. Ты занимашся технологиями прошлого века. Тот же винформс
>> даст им 100-кртаную фору.

C>Для C# нет нормальной поддержки VBA. Был VSA, но МС его перестал продавать.

А VBA ваша компания в состоянии купить? VSA как было так и есть. Можешь пользоватьс бесплатно. Ну, а VS можно купить и отдельно. В сором времени появятся Express-ы которые вообще будет чуть ли не бесплатны.

Ради хохмы погляди вот на это http://www.divil.co.uk/net/articles/designers/hosting.asp

VladD2 пишет:

> C>Да, но какая _практическая_ польза будет от него? Его свойства нельзя
> C>будет редактировать визуально из VB/Delphi, а это и есть главное
> C>достоинство AXов.
> Заходишь в VS... создашь проект "ATL Project"... Выбирашь добавит
> класс... Выбирашь "ATL Control"... В диалоге содания на закладке
> "Options" выбирашь "Interface: Custom"... Добавляешь свойство... Идешь
> в Дельфи, VS (хоть в дотнет) или ВБ6 и видшь что все ОК.

Сделал (естественно, не пометив интерфейс как automation compatible).
Добавляю в VB6: "Unexpected error (35005)". Тоже самое, но с дуальным
интерфейсом прокатывает без проблем. Делфи у меня не стоит, так что
проверить не могу.

> Далее думашь за каких хреном создал это доисторическое убожщен так как
> и новый ВБ и Шарп прекрасно живут с ВыньФормсовыми контролами которые
> и создавать и поддерживать в сто раз проще.

Ага, а как мне их заюзать из моего отстойного, устаревшего приложения на
С++?

> C>Для C# нет нормальной поддержки VBA. Был VSA, но МС его перестал
> продавать.
> А VBA ваша компания в состоянии *купить*?

Да. Стоит он не так дорого — около $10000, без всяких run-time лицензий.
А я уже говорил, кажется, что мы пишем софт для всяких Porsche

> VSA как было так и есть.

Нет. Нам его _отказались_ продавать, сказали: "Берите VBA". В общем, не
понимаю я политику МС в этом вопросе.

> Можешь пользоватьс бесплатно. Ну, а VS можно купить и отдельно. В
> сором времени появятся Express-ы которые вообще будет чуть ли не
> бесплатны.

И как мне их распространять со своим продуктом? По VSIP-лицензии (тоже
за $10k)?

> Ради хохмы погляди вот на это
> http://www.divil.co.uk/net/articles/designers/hosting.asp

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>_wqwa пишет:

>> C>Согласен, реализация Свинга хромает (хотя последние версии очень даже
>> C>нормальны). У меня просто это такая несбыточная мечта, что кто-нибудь
>> C>наконец-то создаст нормальный GUI-фрэймворк.
>> И очень даже сбыточная Эпловую Cocoa видел? Мне очень нравится!

C>Я вообще на OS X смотрю и плачу. Все в ней сделано правильно (по
C>сравнению с Win/Lin), а вот использовать — нельзя Так как уровень
C>распространения Маков ~0.
а в свете того что есть такая система как дарвин?
и то, что маки двинулись в сторону IBM совместимых машин. Смотрел ли на это более внимательно? может стоит уже начинать двигатся в эту сторону?

З.Ы.
перечитывал архивы, уж извините янусопоклонники что поднял тему..

ironwit wrote:

> C>Я вообще на OS X смотрю и плачу. Все в ней сделано правильно (по
> C>сравнению с Win/Lin), а вот использовать — нельзя Так как уровень
> C>распространения Маков ~0.
> а в свете того что есть такая система как дарвин?

Ну есть. Без закрытой Aqua это просто очередная BSD.

> и то, что маки двинулись в сторону IBM совместимых машин. Смотрел ли
> на это более внимательно? может стоит уже начинать двигатся в эту сторону?

Да какая разница. Они публично заявили, что MacOS X _НЕ_ будет работать
на обычных x86-компьютерах, то есть все равно нужно будет покупать их
дорогое железо.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>ironwit wrote:

>> C>Я вообще на OS X смотрю и плачу. Все в ней сделано правильно (по
>> C>сравнению с Win/Lin), а вот использовать — нельзя Так как уровень
>> C>распространения Маков ~0.
>> а в свете того что есть такая система как дарвин?

C>Ну есть. Без закрытой Aqua это просто очередная BSD.

>> и то, что маки двинулись в сторону IBM совместимых машин. Смотрел ли
>> на это более внимательно? может стоит уже начинать двигатся в эту сторону?

C>Да какая разница. Они публично заявили, что MacOS X _НЕ_ будет работать
C>на обычных x86-компьютерах, то есть все равно нужно будет покупать их
C>дорогое железо.

Понял, спасибо