VladD2 wrote:
>> > Так проблема в том, что сам язык не очень подходит для вывода типов.
>> > Отсюда и трудности. Проще сразу ввести в язык нужные ограничения. Тогда
>> > вывод типов из шаманста становится четким алгоритмом.
> C>Просто вывод типов нужно делать постоянно.
> В рантайме? Ну, так это и будет интерпретацией.
Да. Интерпретацией это не будет, так как деревья тут же будут JITится.

> C>А вот почитатели динамических языков так не считают. И примеры
> C>Ruby'шного кода, которые приводит eao197 показывают, что это вполне
> полезно.
> Ну, вот я как-то не вижу особой разницы в коде при том, что вижу разницу
> в контроле, надежности и скорости.
Динамические языки с их возможностью автоморфинга кода дают некоторые
уникальные возможности. И естественно, отбирают некоторые ценные
возможности статической типизации. В общем, trade-off'ы как всегда.

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

VD>Хм. А не лучше (а главное логичнее) было бы ввести в язык алиасы (что-то вроде typedef, но порождающий новый тип)?

Да, почти об этом речь, но только не для этой задачи.

Ведь прикол этой задачи в том, чтобы мы делили дистанцию на время и в результате получали скорость. Для .Net либо же языка с предложенными алиасами сложность заключается в том, что невозможно описать всевозможные комбинации номинаторов/деноминаторов для всевозможных физических величин, которые получаются как промежуточный результат в формулах, например. Иными словами, красота решения на С++ в том, что это решение через одноразовую запись для каждой операции (+-*/) выражает в абстракной форме ЗАВИСИМОСТЬ м/у типами. Если в дотнет ввести в параметр генерика интегральную величину (а технических трудностей вроде не видно), то можно будет решить эту задачу (а заодно и еще многие другие).

V>>Т.е. выделение домена — это как бы естественно при проектировании прикладного кода.

VD>Ага. Не естественнен способ которым это делается.

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

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

V>>Да. Особенно в прикладном коде. Особенно там, где сложность формул преттендует на write-only... хоть какая-то проверка на "здравый смысл".

VD>Ну, привел бы пример из своего кода. И статистику сколько их таких.

Сколько их — зависит от от характера задач. Когда я писал прогу для расчета импульсных трансфоматоров — это километры расчетов всевозможных параметров по сходящимся алгоритмам. Статистика была под 99% Жаль, что на тот момент (99-й год) мне не пришло в голову использовать подобные трюки, поэтому отладка была болезненной.


А вот кусок из недавнего (прога — решетка фильтров и преобразователей спектра):

#pragma once

#include "SoundDeviceImpl.h"

namespace SoundCore {

    // inputs number - 0, outputs - 1 
    class SinGenerator : public SoundDeviceImpl<SinGenerator, 0, 1> 
    {
        typedef SoundDeviceImpl<SinGenerator, 0, 1> super;

        freq_t freq;
        phase_t df;
        phase_t currentf;

        const phase_t PI2 = phase_t(2*3.1415926535897932384626433832795);

        static DeviceDescriptorImpl<SinGenerator> descriptor;
        
    public:
        SinGenerator() : freq(500), currentf(0) {}
        
        virtual DeviceDescriptor GetDescriptor() {
            return descriptor;
        }

        freq_t GetFrequency() {
            return freq; 
        }

        void SetFrequency(freq_t value) { 
            freq = value;
            PrepareImpl();
        }

        void PrepareImpl() {
            super::PrepareImpl();
            df = PI2 * freq / GetSampleFreq();
        }

        float CalculateImpl() {
            currentf += df;
            
            if (currentf > PI2) 
                currentf -= PI2;
                
            output = Sin(_currentf);
        }

        inline static ampl_t Sin(phase_t value) {
            return ampl_t(SinFromTable(value));
        }
    };
}

Заметь, подобный код дополнительно самодокументируем.

А на самом деле речь идет о том, что в идеале, если код скомпилировался, то охота верить, что в 99% случаев он верен... это нормально для сильной статической типизации.

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


FR>>Пусть так но мне хочется понять насколько велики возможности немерли. Просто если реализация очень сложна то практически можно сказать что этой возможности нет.

VD>Что значит очень? Она достаточно сложна, чтобы не заниматься ею ради пенисометрии. Будет надо — сделаю.

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

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

E>А кто говорил, что unit-тесты должны быть всегда?

Те кто призывает программировать на нанамически типизированных языках.

E>К тому же формы, имхо, не unit-тестами проверяют, а функциональными.

Формы это один пример из множества. Я часто встречал задачи в кторых юнит тесты не дают осбобого толку.

VD>>Естественно. На то NCC и отдельный процесс. Только как это может помешать его отладке?

E>Отсутствие Visual Studio на машине, например, как ты только что сказал по секрету.

Очередная фобия? В .NET SDK входит отладчик. Не хуже студщии.

E>Для тех, кто в танке:

Это ты сам с собой?

E> я не мог сообразить сначала, что отладка compile-time макроса должна осуществляться как отладка отдельного процесса ncc. Вот и все.

Заметь, пришлось повторить объяснение минимум 10 раз пока дошло до танкистов.

E> Может ты уже при работе с Nemerle к таким заморочкам привык, но для других это может быть чем-то новым.

Я к таким вещам привых уже давно. Любая компонентная технология приводит к этому. Чтобы, например, отладить контрол (АктивыкС, дотнетынй и т.п.) приходится грузить IDE как хост-процесс. Собственно при отладки мидл-вари происходит тоже самое.

E>assert-ы банально вырубаются при NDEBUG.

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

E> А вот asm { int 3h; } так не выключишь.

Что обычно как раз фигово.

VD>> А asm в С++ в общем-то и нет. Это расширение некоторых компиляторов. К С++ имеет такое же отношение как, например, поддержка COM-а.

E>Не расписывайся в очередной раз в незнании C++:
E>

E>7.4 The asm declaration [dcl.asm]
E>An asm declaration has the form
E>

E> asm-definition:
E>   asm ( string-literal ) ;
E>

E>The meaning of an asm declaration is implementation-defined. [Note: Typically it is used to pass informa-
E>tion through the implementation to an assembler. ]

E>Т.е. ключевое слово asm -- это часть языка. А вот то, что внутри asm -- это уже зависит от компилятора.

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

Да, и какая разница? Один хрен стандарта на ассемблер нет. А int 3 есть вообще только на PC.

E>Я говорил о том, что вставка Assert(false) в текст макроса Nemerle для того, чтобы ncc вывалился в нужном месте в отладчик, очень напоминает вставку int 3 в код C/C++ программы для того, чтобы программа вывалилась в нужном месте. Не макрос C/C++, не шаблон C++, а программа C/C++.

Вообще-то скорее напоминает всавку ASSERT(FALSE), но опять же это если проводить аналогии с рантаймом. В С++-макрокоде твои инты и ASSERT(FALSE)-ы не сработают.

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

C>Да. Интерпретацией это не будет, так как деревья тут же будут JITится.

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

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

Даже у относительно статичной Явы и дотнета есть определенные трудности с оптимизацией в следствии того, что типы могут подгружаться динамически. А уж у Питонов и Рубей с этим просто задница. Между тем потребонсть в полной и постоянно динамике нет. Так что лично я склоняюсь к тому, что идея оптимизации скриптов — тупиковая идея.

C>Динамические языки с их возможностью автоморфинга кода дают некоторые
C>уникальные возможности. И естественно, отбирают некоторые ценные
C>возможности статической типизации. В общем, trade-off'ы как всегда.

Динамическая самомодицикация кода причиняет вред который давно поисан многими исследователями. И как раз макросы являются отличной заменой самомодицикации кода.

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

V>И все из-за невозможности в дотнет использовать интегральных констант в качестве параметров генериков. Тогда бы решалась в лет и можно было бы сделать не пенисонометрии ради, а спокойствия за код для.

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

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

Как выглядит SoundDeviceImpl? И зачем вообще все эти изыски?

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

WH>>Ты можешь не верить но когда я пишу на C# все примерно так и происходит. Я могу несколько дней долбить код без компиляции. После компиляции (как правило все компилируется сразу ибо ReSharper рулит) и устранении пары исключений (причем на C#2 и этого скорей всего не понадобится ибо генерики) все действительно работает как надо.

E>Ты прав. Не поверю.

Ну, так попробуй. Блин, живешь в своем мире и ходишь на форум чтобы не верить остальным. Какой смысл вообще о чем-то говорить, если верить ты не веришь, а пробовать не хочешь.

E>Ты можешь мне не верить, но наведенки в C++ у меня встречаются всего пару раз за год.

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

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

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

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

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

C>Классы — элементарно заменяются COM-интерфейсами. Массивы, строки —
C>SAFEARRAY, BSTR. Исключения — HRESULT+IErrorInfo.

Неужели так охота иметь секс с этим убожеством вместо нормальной бабы?

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

E>>Ты можешь мне не верить, но наведенки в C++ у меня встречаются всего пару раз за год.

VD>Да, уж не поверю.

Блин, живешь в своем мире и ходишь на форум чтобы не верить остальным.

Если у тебя лично с C++ не сложилось, не переноси свои переживания на других.

VladD2 wrote:
> C>Да. Интерпретацией это не будет, так как деревья тут же будут JITится.
> Понимаш ли в чем дело? Смысла знаниматься компиляцией и распознованием
> одновремнно нет. Тормоза от распознований съедят основную часть выигрыша
> от компиляции.
Скажите это товарищам из Sun'а. HotSpot JVM этим уже 8 лет занимается —
отслеживается CFG (Control Flow Graph) для инлайнинга вызовов
виртуальных функций. Причем динамически в рантайме.

Конечно, для инлайнинга name-based полиморфных функций придется сделать
намного больше работы. Но надо же чем-то занять более мощные процессоры?

> Так что лично я склоняюсь к тому, что идея оптимизации скриптов — тупиковая идея.
По крайней мере это поинтереснее очередного JITа для C#.

> C>Динамические языки с их возможностью автоморфинга кода дают некоторые
> C>уникальные возможности. И естественно, отбирают некоторые ценные
> C>возможности статической типизации. В общем, trade-off'ы как всегда.
> Динамическая самомодицикация кода причиняет вред который давно поисан
> многими исследователями. И как раз макросы являются отличной заменой
> самомодицикации кода.
Я тут за все время так и не заметил полезных примеров применения
макросов на Немерле. А вот eao197 приводил вполне полезные примеры из
своей build-системы.

VladD2 wrote:
> C>Классы — элементарно заменяются COM-интерфейсами. Массивы, строки —
> C>SAFEARRAY, BSTR. Исключения — HRESULT+IErrorInfo.
> Неужели так охота иметь секс с этим убожеством вместо нормальной бабы?
Нет, так как с "нормальной бабой" в комплекте обязательно идет сифилис
(Microsoft), триппер (GC) и СПИД (тормоза).

VladD2 wrote:
> C>Откуда он "заранее известен"? У нас есть на него стандарт?
> Это один из способов. Собственно он подразумевает наличие такого
> стандарта. Ты воодишь интерфейс который реализуется динамическим
> объектом. Очень частый случай. Интежфейс может быть как интерфейсом в
> полном смысле этого слова, так и неким делегатом/фанктором.
Вот это давно пора сделать.

>> > С Эллочкой сранвивать не буду. Но где-то в ЯП есть лучше?
> C>В той же ParrotVM, например.
> Осталось только доказать это утверждение. Без этого с тем же успехом его
> можно назвать полным отстоем.
ParrotVM поддерживает множественное наследование, замыкания,
мультиметоды, динамические вызовы, больше встроеных типов данных.

> C>Есть. В .NET нет проблем только с рефлексивными вызовами.
> Это тоже пустые слова.
Ну так покажите пример интеропа нескольких разных динамических языков.

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

VD>Динамическая самомодицикация кода причиняет вред который давно поисан многими исследователями.

Огласите весь список, пожалуйста

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

E>Если у тебя лично с C++ не сложилось, не переноси свои переживания на других.

У меня с С++ все сложилось замечательно. И именно по этому я сравниваю другие языки с ним.

Ты же ворчишь на то что в глаза не видел.

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

C>Скажите это товарищам из Sun'а. HotSpot JVM этим уже 8 лет занимается —
C>отслеживается CFG (Control Flow Graph) для инлайнинга вызовов
C>виртуальных функций. Причем динамически в рантайме.

Сказки не рассказывай. Есть исследовательские работы. Приемуществнно IBM-овские. Но в ХотСпоте пока что таких оптимизаций нет. Да и анализ там не постоянный, а при подгрузке типов. Слава богу ява не позволяет изменять загруженные классы.

C>Конечно, для инлайнинга name-based полиморфных функций придется сделать
C>намного больше работы.

Ага. А судя по том, что коропрации вроде MS, Sun и IBM не сделали это пока для Явы с Шарпом, можно сделать вывод, что задача крайне сложная если нужны не научные звания, а действительно быстрый код.

C>Но надо же чем-то занять более мощные процессоры?

О. С этим проблем нет.

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

>> Так что лично я склоняюсь к тому, что идея оптимизации скриптов — тупиковая идея.
C>По крайней мере это поинтереснее очередного JITа для C#.

Интерес и полезность для общества разные вещи. Многие исследователи с упоением занимаются разной фигней. Лично мне намного интереснее исследования в области управляемых ОС (кстати, вот перевод статьи о Сингулярити) и метапрограммирования (рефлексии времени компиляции, макросов...).

C>Я тут за все время так и не заметил полезных примеров применения
C>макросов на Немерле.

Пол Немерла — это полезное применение макросов. А у тебя не в одном глазу. Тут дело не в Немерле, а в глазах.

C> А вот eao197 приводил вполне полезные примеры из
C>своей build-системы.

Скорее, бесполезные. На Немерле можно создать подобную систему и она даже будет куда более строго контролировать формат выдавая понятные сообщения об ошибках. Но зачем это делать кода есть Ant и MSBuild?

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

ANS>Огласите весь список, пожалуйста

В сети с ходу не нашел. Об этом много писалось в книжках исторической направленности, так как на заре компьютеризации самомдификация кода была очень распространенной, но потом ее признали очень опасной, так как они усложняет отладку программы и соотвественно делает ее очень непредсказуемой. Собственно об этом у нас даже Зверек как-то говорил http://rsdn.ru/article/philosophy/languages.xml

Автор(ы): Зверёк Харьковский
Дата: 01.04.2005
Потаенные (англ. esoteric – они же эзотерические, тайные и понятные лишь посвященным) Языки Программирования испокон веков (1972) создавались для раздвижения границ возможного, удивления себе подобных и почесывания левой пяткой правого уха – только не для того, чтобы писать на них программы...

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

C>Вот это давно пора сделать.

Это давно сделано. Проблема в самой динамической генераци. В дотнете пока что приходится для иэтого пользоватьс Эмитом. Или довольно медленными средствами компиляции из исходников на лету.

C>ParrotVM поддерживает множественное наследование,

Говорить о вреде МН я не намерен. Придерживался и придерживюсь этой точки зрения. Так что для меня этот пункт минус, а не плюс.

C> замыкания,

Для них не нужна подержка VM. Это языковая конструкция. Немерле отлично поддерживает замыкания на уровне методов (да и Шарп поддерживает). Да и любой класс по сути является заымканием.

C>мультиметоды,

То же самое. Да и мультиметоды никакого отношения к ООП не имеют.

C> динамические вызовы,

Есть в чем проблема с динамическими вызовами в дотнете?

C> больше встроеных типов данных.

1. Это только слова.
2. "Больше" не значит "лучше". Ты докажи, что они нужны, вот тогда и поговрим.


Итак, твои заявления о более широкой поддержке ООП пока что меня не убедили. Скорее наоборот.

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

Все языки реализующие CLS-потребительль/CLS-производитель совместимы друг с другом без интеропа. Показывать тут просто нечего. Лечите свои фобии.