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

C>И какие в этом преимущества? Точно так же, берем обычный
C>рекурсивно-нисходящий парсер, пишем для него грамматику DSLя и
C>транслятор в целевой язык (Java, например). Трудозатраты примерно такие же.

Так, в качестве заметки. DSL совершенно не обязаны быть текстовыми. Вполне допустимо (а на практике очень даже допустимо) наличие графических DSL.

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

C>И какие в этом преимущества? Точно так же, берем обычный
C>рекурсивно-нисходящий парсер, пишем для него грамматику DSLя и
C>транслятор в целевой язык (Java, например). Трудозатраты примерно такие же.

Правда? Сомневаюсь.

Вот, кстати, можно эксперимент провести. Недавно на Lambda-the-Ultimate был предложен Cellang в качестве примера (http://staff.vbi.vt.edu/dana/ca/cellular.shtml).

Хороший такой этюд для программистов.

Gaperton wrote:

> C>А нафиг? Мне хватает однопоточного.
> Тогда конечно все проще, везет тебе. Еще ложка дегтя — это работает
> очень медленно — насколько я помню VBA в этом режиме интерпретирующий.

Да, с предварительной трансляцией в P-код.

> Впрочем, в этом смысле должно быть не хуже Питона. Ну и, ктати, если
> тебе в будущем понадобится несколько инстансов VBA runtime в одном
> процессе — придется вешаться.

На это я уже наткнулся

> C>VBA — это сам по себе DSL, с достаточно широким доменом.
> Ну какой это *Domain Specific *Language.

VBA — это DSL, а домен у него — автоматизация оффисных приложений,
причем для этих целей его вполне хватает.

>>> C>Агащаз. Даже отладчик типа VBAшного — это недели работы, автокомплит и
>>> C>среда разработки — месяцы.
>>> Eclipse.
> C>Ява не умеет OLE, например.
> "OLE, OLE — это просто слезы" (с). А оно нужно, если пишешь на яве?

Да, нужно. Нужны фичи типа возможности вставлять в наш документ
диаграммы из Excel'я или вставлять наши документы в Ворд.

> 1) Есть COM-CORBA прокси. А CORBA ява умеет.

И при этом работает со всеми OLE-интерфейсами (которые с Automation не
совместимы), маршалирует графические вызовы и т.п.? Не верю.

> 2) Есть прямой Java-.NET interop от сторонних производителей.

Нафиг мне .NET сдался? Он тоже не умеет OLE.

> 3) В конце концов есть нативные интерфейсы, через которые можно все.
> Только нафига?

Угу, получится что все приложение будет написано на C++ с запускальщиком
на Java.

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

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

>> Впрочем, в этом смысле должно быть не хуже Питона. Ну и, ктати, если
>> тебе в будущем понадобится несколько инстансов VBA runtime в одном
>> процессе — придется вешаться.

C>На это я уже наткнулся

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

>> C>VBA — это сам по себе DSL, с достаточно широким доменом.
>> Ну какой это *Domain Specific *Language.
C>VBA — это DSL, а домен у него — автоматизация оффисных приложений,
C>причем для этих целей его вполне хватает.
DSL — это когда ты свой язык делаешь для задачи. Где у тебя предметная область поддерживается на уровне языковых конструкций. Это не случай VBA — там ты всего-лишь имеешь возможность кастомизировать библиотеку. Если тебе этого хватает — это замечательно, но от этого VBA не становится DSL.

>>>> C>Агащаз. Даже отладчик типа VBAшного — это недели работы, автокомплит и
>>>> C>среда разработки — месяцы.
>>>> Eclipse.
>> C>Ява не умеет OLE, например.
>> "OLE, OLE — это просто слезы" (с). А оно нужно, если пишешь на яве?

C>Да, нужно. Нужны фичи типа возможности вставлять в наш документ
C>диаграммы из Excel'я или вставлять наши документы в Ворд.

>> 3) В конце концов есть нативные интерфейсы, через которые можно все.
>> Только нафига?

C>Угу, получится что все приложение будет написано на C++ с запускальщиком
C>на Java.
Нет, если делать не через зад, а по человечески, то получится приложение на Java c native интерфейсами на С++ к COM-объектам. Но ты не подумай, я совсем не советую тебе использовать Java для твоей задачи. Просто хочу донести до тебя мысль, что со всем этим микрософтным добром халявы не будет. Мы год назад через это проходили, и пришли к выводу что с теми же затратами можно было и свою среду разработки со своим языком слабать. Только рисков меньше, и результат именно тот, который ты ожидаешь. Без сюрпризов.

Gaperton wrote:

>>> Впрочем, в этом смысле должно быть не хуже Питона. Ну и, ктати, если
>>> тебе в будущем понадобится несколько инстансов VBA runtime в одном
>>> процессе — придется вешаться.
> C>На это я уже наткнулся
> А говоришь, не нужен многопоточный режим .

А он мне не нужен, мне было нужно несколько инстансов VBA в одном процессе.

> Тебе придется его использовать, чтобы решить эту проблему.

Уже давно решили, обошлись одним VBA

>
> C>VBA — это DSL, а домен у него — автоматизация оффисных приложений,
> C>причем для этих целей его вполне хватает.
> DSL — это когда ты свой язык делаешь для задачи. Где у тебя предметная
> область поддерживается на уровне языковых конструкций.

Именно. В VBA на уровне "языковых конструкций" (формочек, модулей
кода...) поддерживается автоматизация приложений, VBA как раз под это и
был заточен.

>>> Только нафига?
> C>Угу, получится что все приложение будет написано на C++ с
> запускальщиком
> C>на Java.
> Нет, если делать не через зад, а по человечески, то получится
> приложение на Java c native интерфейсами на С++ к COM-объектам.

Теоретик.... OLE — это ведь не просто три буквы, это и определенная
организация приложения, и КУЧА интерфейсов. Все это скрещивать с Явой —
ну уж нет, лучше на старом добром С++.

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

Мы тоже смотрели, VBA мне лично не особо нравится. Но вот в том-то и
дело, что других решиений _НЕТ_. Есть VSIP (еще не очень дозревший) и
есть несколько сред аля-VBA (спроси у Vlad'а). Ни одна из них не
поддерживает user-friendly (а это для нас главное) редактирование
формочек и кода.

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

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

G>А ReSharper сможет работать с вашим собственным языком и достанется вашим клиентам бесплатно?
Собственный язык не обезателен см ниже.
А ReSharper это дополнительная мегафича за отдельные деньги.
G>Вы, батенька, вообще в курсе, что такое DSL?
Domain-Specific Language
Вобще говоря чтобы создать DSL не обязательно создавать новый язык.
Мозги + библиотека + пара кодогенераторов и получаем DSL как правило мало уступающей созданию нового языка.
Но имеющий огромные преймущества а именно мощьный отладчик, интелисенс,... а елси поставить еще и внешние примочки типа ReSharper'а то вобще
G>Кстати, я работая на С++ прекрасно обхожусь без вашего ReSharpera. И неудержимой тяги писать его аналог не испытываю.
Я тоже не испытывал пока не попробовал. Вобщем ReSharper это наркотик такой.

WolfHound wrote:
> G>Кстати, я работая на С++ прекрасно обхожусь без вашего ReSharpera. И неудержимой тяги писать его аналог не испытываю.
> Я тоже не испытывал пока не попробовал. Вобщем ReSharper это наркотик такой.

ReSharper это полный аналог возможностей IDEA, или еще что-то уникальное?

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

C>FR wrote:

>> C>А _откуда_ PyChecker узнает, что some_external_function возвращает
>> C>переменную типа Test? Язык-то динамический.
>> Сначала он импортирует все модули и все что можно проанализировать
>> анализирует,
>> Потом все таки запускает программу, и тоже анализирует.

C>Это значит "вернутся на клетку 1", то есть мы не можем убедится в
C>корректности программы пока ее не запустим.

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

>> C>Нету его там в нормальном. Есть name-based polymorphism, который по
>> сути
>> C>тоже есть в шаблонах С++, это используется для CRTP (Curously Recurring
>> C>Template Pattern).
>> однако это не мешает легко писать на питоне обобщенный и повторно
>> используймый код

C>А необобщенный (чиста конкретный) код на Python'е писать можно?

можно, если осторожно

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

C>Да, поэтому и важна их отлаживаемость и удобство написания.

Угу только почему-то отлаживатся и писать на питоне очень удобно, парадокс?
Вот к примеру прототипирование у меня сейчас посчти полностью на питоне, и даже когда надо отладить какой ни будь достаточно сложный алгоритмически кусок кода, быстрее получается сделать это на питоне, и потом переписать например на C++.

_vovin wrote:

>> G>Кстати, я работая на С++ прекрасно обхожусь без вашего ReSharpera.
> И неудержимой тяги писать его аналог не испытываю.
>> Я тоже не испытывал пока не попробовал. Вобщем ReSharper это наркотик
> такой.
> ReSharper это полный аналог возможностей IDEA, или еще что-то уникальное?

Почти полный, его пишут те же люди, что и IDEA. Хотя по сравнению с IDEA
он часто глючит.

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

Cyberax wrote:

> _vovin wrote:
>
>
>>>G>Кстати, я работая на С++ прекрасно обхожусь без вашего ReSharpera.
>>
>>И неудержимой тяги писать его аналог не испытываю.
>>
>>>Я тоже не испытывал пока не попробовал. Вобщем ReSharper это наркотик
>>
>>такой.
>>ReSharper это полный аналог возможностей IDEA, или еще что-то уникальное?
>
>
> Почти полный, его пишут те же люди, что и IDEA. Хотя по сравнению с IDEA
> он часто глючит.
>

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

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

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

FR>>>А отсутствие типизпции может быть и преимуществом.
WH>>Да правда чтоли? Интересно почему тогда весь мейнстрем типизированый по самое нехочу?
G>Да правда чтоли? VB со своим IDispatch, JScript, PHP, Perl и ваш любимый C# c контейнерами Object-ов — типизированны по самое нехочу?

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

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

C>Gaperton wrote:

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

>>>> Только нафига?
>> C>Угу, получится что все приложение будет написано на C++ с
>> запускальщиком
>> C>на Java.
>> Нет, если делать не через зад, а по человечески, то получится
>> приложение на Java c native интерфейсами на С++ к COM-объектам.
C>Теоретик.... OLE — это ведь не просто три буквы, это и определенная
C>организация приложения, и КУЧА интерфейсов. Все это скрещивать с Явой —
C>ну уж нет, лучше на старом добром С++.
Да где уж нам до практиков.
1) COM для вас превратится в три не простых, а очень веселых буквы (разрастание кода вдвое), как только выльется в "определенную организацию приложения" на "старом добром с++".
2) Java — это не просто четыре буквы, но тоже вполне определенная организация приложения.

Впрочем, переубеждать вас не буду — мне в каком-то смысле на руку, что вы (и другие) пишете именно так.

Gaperton wrote:

> C>А он мне не нужен, мне было нужно несколько инстансов VBA в одном
> процессе.
> Нужен, ибо в этом режиме как раз *можно *включать несколько инстансов
> VBA в одном процессе, в чем и состоит его основная польза. Впрочем, не
> нужен и не нужен, твое дело.

У этого MT VBA слишком большая куча глюков, чтобы его нормально
использовать.

> C>Теоретик.... OLE — это ведь не просто три буквы, это и определенная
> C>организация приложения, и КУЧА интерфейсов. Все это скрещивать с Явой —
> C>ну уж нет, лучше на старом добром С++.
> Да где уж нам до практиков.
> 1) COM для вас превратится в три не простых, а очень веселых буквы
> (разрастание кода вдвое), как только выльется в "определенную
> организацию приложения" на "старом добром с++".

Нет, у нас код из-за COM не разрастается (используем Comet вместо ATL),
да и организация интерфейсов в OLE достаточно разумная.

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

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

C>Нет, у нас код из-за COM не разрастается (используем Comet вместо ATL),
C>да и организация интерфейсов в OLE достаточно разумная.

Хм, Comet, говоришь? Ща посмотрим...

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

WH>>нажимаю пару кнопок и получаю
WH>>

WH>>        private float Foo(int i, string s)
WH>>        {
WH>>            throw new NotImplementedException();
WH>>        }
WH>>

WH>>красота

ANS>Столько сложностей и всё ради того, чтобы получить ошибку времени выполнения!
Ну, кстати да. По идее, туда надо емиттить

private float Foo(int i, string s)
{
  #error Missing method body for private float MyClass.Foo(int, string);
  // throw new NotImplementedException(); 
}

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

ANS>>Столько сложностей и всё ради того, чтобы получить ошибку времени выполнения!
S>Ну, кстати да. По идее, туда надо емиттить
S>

S>private float Foo(int i, string s)
S>{
S>  #error Missing method body for private float MyClass.Foo(int, string);
S>  // throw new NotImplementedException(); 
S>}
S>

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

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

AVK>И в результате ничего не скомпилируется, пока не напишешь реализацию всех методов.
Именно. В чем цель и состоит. А то при массовом рефакторинге можно и забыть тело-то приписать. Так и доедет до юнит-тестирования недописанным
Можно и warning — по вкусу. Это просто уж совсем параноидальная опция — требует вручную пойти и раскомментировать throw, выкосив еррор. ъ.

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

AVK>>И в результате ничего не скомпилируется, пока не напишешь реализацию всех методов.
S>Именно. В чем цель и состоит. А то при массовом рефакторинге можно и забыть тело-то приписать. Так и доедет до юнит-тестирования недописанным

Это не рефакторинг, это написание нового кода.

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

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

AVK>>И в результате ничего не скомпилируется, пока не напишешь реализацию всех методов.
S>Именно. В чем цель и состоит.
ага. зато потестить кусок функционала не получится.
уж лучше совместить warning и exception

C>>Вообще, за такой код (с утечками ресурсов) я бы отрывал головы...

FR>где ты здесь увидел утечки ресурсов? Файлы по любому закроются на выходе.

Угу закроются. Давайте вообще перестанем файлы закрывать, , они "полюбому закроются на выходе", или при Segmentation fault.
Пусть ОС заботится о закрытии файлов, как сборщик мусора заботится о мертых ссылках.