Будущее C# - Философия программирования

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

S>Это потому, что ошибки дизайна могут быть только в конкретном дизайне

А мы никакой конкретный дизайн пока не обсуждаем.

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

S>Это доказывает только то, что тебе макросы привычнее шаблонов.

Вовсе нет. Просто задача решалась значительно проще на макросах. Был бы приличный генератор кода подрукой выбрал бы его.

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

S>Ну, он и выглядит нормально, если уметь на него смотреть.

— Ген! Сомотри... Мой портрет!
— Чебурашка, а что это он какой-то странный?
— Чем?
— Ну, он весь как-то стнанно разлинован и вообще...
— А! Это его месник рисовал... Он так видит!

S> Мне вот часто говорят, что функционально программирование полный рулез и показывают какой-то код на OCML'е, который на мой посторонний взгляд просто ужасен

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

Ничего не могу скзать по причине не знания OCML-я. Хотя в отношении Модулы у меня такое же впечатление. Но это концепции. А тут речь о банальном излишестве кода на еденицу полезного действия. Бывают кстати и обратные перегибы. Например, регэкспы.

S>А это не лишнее — это то же самое, что и атрибут с параметрами для переменной выставить.

Вот ттлько атрибуты появляются изреда, не занимают времени компилятора и не засоряют код.

S>Хм, а если я хочу из edit'а float'овские данные забирать без написания лишнего кода? Да еще с валидацией?

Тогда ты пишешь класс редактирующий float-ы и потом всю жизнь пользуешся с ним. Это же ОО.

Если влом писать лезешь в Интернет за халявой или платными продуктами.

S>Ну дык код-то генерировать придется уже в рантайме, на машине клиента.

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

S>У нас просто разные понятия о минимуме затрат

Да. Для меня это бестрый результат с минимум напряжения.

VD>>Что значит еще? Идее метапрограммирования думаю столько же лет сколько существуют высокоуровневые языки.

S>Ссылки и цитаты, плиз.

Я тут не специалист. Погляди в гугле на слова SML, Prolog, Lisp, Smalltalk. Все они имеют зачатки метапрограммирования которые появились очень давно. Хотя еще раз повторю в этой области я профан.

S>Ты его явно демонизируешь

Возможно. Через лет пять увидим.

S>Чья бы корова мычала

"А до генераторов кода этому подходу как до Пекина раком." и т.д., причем абсолютно бездоказательно.

Ты генераторы кода видел? Мне кажется — это очевидно. Те же макросы имеют куда большие возможности ито не дотягивают до генераторов по возможностям.

S>Ну а ты головой-то подумай, что надежней будет: сгенерировать код компилятором у себя на машине, и тут же все ошибки увидеть, или генерировать его на машине клиента?

Это ты подумай. Генерит код-то машина. Если алгоритм генерации правильный, то код будет даже надежнее рукописного. Он же по алгортму сделан. А отлафивается код один фиг в конечном счете прогонами. Так что однажды отлаженный генератор будет довать очень даже надежный код.

S>Бездоказательное пустозвонство

Ты даже код, который это делает, не видел.

Нуда нам серым. Вот изобрази на шаблонах хотя бы вот такой примитив, а потом поговорим:
Файл с описанием структуры таблиц (CODER_TOKEN_DEF.h):

CODER_TOKEN_DEF_BEGIN(TypeDefOrRef)
    CODER_TOKEN_DEF_TABLE(TypeDef)
    CODER_TOKEN_DEF_TABLE(TypeRef)
    CODER_TOKEN_DEF_TABLE(TypeSpec)
CODER_TOKEN_DEF_END(TypeDefOrRef)

// И еще много много таких обявлений...

CODER_TOKEN_DEF_BEGIN(ResolutionScope)
    CODER_TOKEN_DEF_TABLE(Module)
    CODER_TOKEN_DEF_TABLE(ModuleRef)
    CODER_TOKEN_DEF_TABLE(AssemblyRef)
    CODER_TOKEN_DEF_TABLE(TypeRef)
CODER_TOKEN_DEF_END(ResolutionScope)

#undef CODER_TOKEN_DEF_BEGIN
#undef CODER_TOKEN_DEF_TABLE
#undef CODER_TOKEN_DEF_END

Описание макросов для генерации методов:

#define CODER_TOKEN_DEF_BEGIN(TokenName)   \
protected:                                                                 \
void InitCodedToken##TokenName()           \
    {                                        \
        const Tbl tables[] =                   \
        {

#define CODER_TOKEN_DEF_TABLE(TableName)            ciTbl##TableName,

#define CODER_TOKEN_DEF_END(TokenName)                             \
        };                                                             \
        int iMaxCnt = m_pSchema->m_cRecs[tables[0]];                   \
        for(int i = 1; i < GetElemCount(tables); i++)                  \
        {                                                              \
            int iCnt = m_pSchema->m_cRecs[tables[i]];                    \
            if(iCnt > iMaxCnt)                                           \
                iMaxCnt = iCnt;                                            \
        }                                                              \
        int iBits = NBits<GetElemCount(tables)>::GetBitsCount();       \
        int iMaxVal = iMaxCnt << iBits;                                \
        const UINT ciMask = 0xFFFF;                                    \
        if(((UINT)(iMaxVal & ciMask)) != iMaxVal)                      \
        {                                                              \
            m_bSize4##TokenName = true;                                  \
            m_iSize##TokenName = 4;                                      \
        }                                                              \
        else                                                           \
        {                                                              \
            m_bSize4##TokenName = false;                                 \
            m_iSize##TokenName = 2;                                      \
        }                                                              \
    }

#include "CODER_TOKEN_DEF.h"

А это для декларации переменных:

#define CODER_TOKEN_DEF_BEGIN(TokenName) m_bSize4##TokenName(false), \
                                         m_iSize##TokenName(0),
#define CODER_TOKEN_DEF_TABLE(TableName)
#define CODER_TOKEN_DEF_END(TokenName)

#include "CODER_TOKEN_DEF.h"

И таких фигней через раз. В итоге создаются десятки (порфдка 40-80 классов) представяющие собой некий АПИ. Вот попробуй создать такое же на шаблонах.

PS

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

... << RSDN@Home 1.1 beta 1 >>

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

S>Ну, код тебе приводить бесполезно,

От чего же? Если он чистый и хорошо читабельный, то гляну. А на навороты глядеть неохота.

S>тебе его лень смотреть, книг ты принципиально не читаешь —

Да ты лучше меня знаешь, что я принципяльно делаю и не делаю. Прям шаман.

S>оставайся при своем мнении.

Ну, хоть на этом спасибо.

VD>>И как ты будешь отлаживать более менее сложный алгоритм засунутый рекурсивный шаблон?
S>Только сообщениями об ошибках, к сожалению.

Во-во. А это при больших объемах кодогенерации оооОочень сложно. Я лично не раз с этим сталкивался. А ведь в таких подходах порой и сообщение некуда впихнуть.

VD>>Или что будешь делать если рекурсия для решения некоторой проблемы не является удобным подходом?
S>Буду использовать boost::mpl, когда фирма, где я работаю, соблаговолит переползти на более стандартный компилятор.

Во-во. Еще и не все компиляторы это дело хавают. А те что хавают начинают безбожно тормозить. Пару сотен таких использований и проект компилируется по 10 минут на P4.

S>Угу, только код-то получаться иногда разный будет, и все его варианты ты по определению не отладишь...

Код плучается по алгоритмам. И нужно отлаживать именно их, а не конечный код. Практика показывает, что чем меньше участие человека тем меньше ошибок. 99% ошибок — это человеческий фактор.

S> И наверняка иногда он вообще с синтаксическими ошибками будет генерироваться — у меня на эти ошибки выругается компилятор еще до поступления кода к пользователю, а у тебя?

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

S>>>Черта с два ты макросами такое сделаешь.
VD>>Ну, ну. В чем проблема?

S>Отлаживаться плохо, например.

Забавные рассуждения. Тяжело == черта с два.

S> Ну и с типобезопастностью дело никудышно у макросов обстоит. Прагму внутрь макроса не вставишь. Да полно у препроцессора недостатков.

Недостатков у препроцессора хаватает. Но в итоге все зависит от рук. Если же говорить, о гибкости, то макросы куда гибче. Тебе же именно гибкость нужна? Руки то у тебя в порядке.

S>Я ее не помню. Ну ладно, потрачу пару минут, найду: http://sourceforge.net/projects/opencxx/

Сенкс. Я вот попробовал поискать и зарылся в хламе. С описанием там как-то туго. Жаль...

VD>>Он к языку привязан?
S>Да.

Жаль.

S>Тебе макросы для шарпа нужны, что ли? А чем плюсовый препроцессор не устраивает?

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

S>Естественно, дольше, чем то, что существует. Новое сначала придумать надо.

... << RSDN@Home 1.1 beta 1 >>

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

VD>>>Ты сказал, что непонятны они только тем кто с ними работать не умеет. Так вот я умею с ними работать очень неплохо.
S>>С шаблонами? Вряд ли.
WH>Согласен.

Гы-гы.

PS

И почему чем неопытнее люди, тем чаще они считают, что уменее всех остальных?

... << RSDN@Home 1.1 beta 1 >>

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

IT>Похоже что твой друг — воинствующий динозавр и убеждать его в обратном не стоит

IT>Сори, не в обиду, но выглядит это никак не иначе.

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

PS

Все имена вымышленные, а совподения не предномеренные.

... << RSDN@Home 1.1 beta 1 >>

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

VD>Дык надо было для этой ячейки классик создать...
Вот я и завел шаблончик

... << RSDN@Home 1.1 alpha 1 >>

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

VD>Неужели они так страшны, что из-за этого нужно изобретать заведомо менее универсальный велосипед?
Мне не нужна уневерсальность. Мне надо как можно меньше гемороя, а GUID, IDL... это геморой.

WH>> Не критично но очень удобно иметь прямой доступ к проперти подобным обьектам.
VD>Так проперти или данным?
Данным косящим под проперти.

VD>Не понял? А какие приемущетсва у С++? В дотнете классы могкут иметь публичные члены. В общем не ясно о чем ты...
Дык перегрузка присваивания запрещена даже у value типов. Следовательно обьект под проперти косить не может. А даже если бы и было в интерфейс всеравно не засунишь. Препроцессор бы помог но и его нету. Остается внешний кодогенератор.

VD>А какова их цель?
Как и у всех остальных шаблонов.
Писать меньше и читать проще. Часто позволяют сэкономить символов 10-50 что очень не плохо.

... << RSDN@Home 1.1 alpha 1 >>

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

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

ГВ>
LVV>>Я лично ЗАПРЕТИЛ применение Борланда 5 и выше, когда исследовал
LVV>>несколько объектных файлов. На х@@. Я хочу спать спокойно.
ГВ>

ГВ>Мда... Слушайте, мож это шутка такая?

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

И я своего друга прекрасно понимаю, так же как и Михаила Донского (одного из авторов Каиссы — первого чемпиона по шахматам среди компьютеров). Он, когда переходил с Лексикона на Word, тоже говорил: мне не нравится, когда меня ВЫНУЖДАЮТ платить за то, что мне не фактически НУЖНО.
Так и С# — не вижу я особых преимуществ ни перед С++, ни перед Java. У этих языков переносимость на 3 порядка выше, чем у до диеза.

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

LVV>Цитата из письма моего друга, активно действующего программиста, руководителя лаборатории и нескольких проектов. Заранее прошу извинения за эмоциональность монго друга, но видимо, у него сильно накипело!

Ну вот, хороший пример теперешней ситуации. Любая новая технология всегда будет встречать яростный отпор и непонимание.

Что же касается данного конкретного человека то видимо его задачи мало связаны с программированием, иначе цифра в 0.05% выглядит просто дико. А поскольку такие люди уже устроились на своем месте и дальше двигаться не желают, то они по прежнему уверены в том что все новое это ересь. До тех пор пока не столкнуться с задачкой, где объем программинга (в особенности модификации уже существующего кода) превысит те самые 0.05%.