Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Dyoma, Вы писали:
D>>Java/C D>>
D>>int sum = 0; // Какого фига я должен думать о том где храню результат?
D>>for (int i = 0; i < array.length; i++) { // Переведи на русский и прочитай вслух :) "Для скобка цел и равно..." :)))
D>> sum += array[i]; // Ну вот это собственно я и думал :)
D>>} // Это тоже надо подумать...
D>>
D>>Smalltalk: D>>array inject: 0 into: [:sum :element | sum + element]
VD>Переведи это на русский и прочитай: VD>
Массив всавил двоеточие ноль в двоеточие квадратная...
Речь шла о возможности думать на языке программирования. Для того, что бы подумать на C/Java даже о простой задаче, приходится отвлекаться на массу лишних даталей.
VD>А на яве тоже ведь можно абстракции вводить. Тогда и на нае все не так страшно: VD>
VD>int sum = Sum(array);
VD>...
VD>static int Sum(int[] array)
VD>{
VD> int sum = 0;
VD> for (int elem: array)
VD> sum += elem;
VD> return sum;
VD>}
VD>
VD>Так что не все так страшно когда к делу с умом подходишь.
Ну и какова применимость этого Sum? А inject:into: можно например использовать для нахождения мин/макс элемента:
array inject: (array get: 0) into: [:min :element | element < min ifTrue:[element] ifFalse:[min]]
Наверняка есть у чисел метод выбирающий минимальный из получатля и аргумента, но я его не помню. Если нет его можно туда добавить.
D>>ML: (за синтакцическую корректность не отвечаю, но только в деталях) D>>fun sum(head::tail) = head + sum(tail) | sum([]) = 0.
VD>B на яве можно писать рекурсивно: VD>
VD>static int Sum(Node list)
VD>{
VD> if (list.getNext() == null)
VD> return 0;
VD> return list.getValue() + Sum(list.getNext());
VD>}
VD>
Разговор о естественных решениях, на C# — естественна итерация по коллекции, на ML — рекурсия. Важная в данном контексте разница в том, что на ML записывая рекурсию, пишется только то, что важно, а на C# тебе пришлось написать if — совершенно лишний в математическом определении рекурсивной функции. А в естественно решении — итерации, приходиться думать где хранить промежуточный результат и помнить про индекс. Т.е. засорять мысль о сложении всех элементов массива, второстепенными подробностями.
VD>Вот толко одно "но". На Яве работа шла с массивом, а на МЛ-е со списком. Со списоком и на Яве будет короче. Но массив эффективнее.
Я хочу думать о проблемах эфективности, тогда когда об этом надо думать. Если проблем с эффективностью нет, то я хочу язык, на котором о них можно не думать, языки типа C меня такой возможности лишают... По этому мне приходится переставать думать на языке программирования и возвращаться к русскому
D>>Вариант от Smalltalk и ML это два разных способа мышления, а Java/C это сплошное спотыкание мысли и куча мусора.
VD>Вообще-то в Смолтоке МЛ-е тоже мусора хоть отбавляй. А что касаемо образа мышления, то если рекурсию МЛ-я я легко понимаю, то Смолток мне кажется чистейшим нагромождением. Может ты к нему привык, но я нет. Мне даже ява ближе.
VD>ЗЫ
VD>А вот так это будет выглядеть на C# 3.0: VD>
VD>Понятнее некуда. VD>Или "вариации на тему": VD>
VD>var sum = array.Fold((fold, second) => fold + second);
VD>
Smalltalk позволяет расширить "словарный запас" и если часто приходится вычислять суммы по коллекции, то в класс Коллекция можно добавить соотвествующий метод.
VD>Ну, и самое простое... C# 1.0: VD>
VD>int sum = 0;
VD>foreach (int elem in array)
VD> sum += elem;
VD>
Опять же разница в том, что foreach — языковая конструкция, ее нельзя выразить на самом C#. Как, например, собрать строку из елементов, разделенную запятимы?
Smalltalk:
array do: [:element | добавляем] separatedBy: [разделяем]
А на С#? Опять итерация и проверяем надо ли ставить разделитель?
Разница в том что do:separatedBy: — метод, если его нет то его можно добавить. А вот foreach separatedBy ты ни в C# ни в java не вставишь...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Cyberax, Вы писали:
C>>Да, хорошие были времена....
VD>Да уж. Чур меня...
C>>У меня тоже гигабайт, но мне ее жалко. Пусть лучше больше памяти в кэш C>>диска уйдет.
VD>Да тебе нужно жабу душить .
Поставь еще один, ну хоть половину. Ты только представь сколько времени ты этим съэкономишь программерам на оптимизации.
Здравствуйте, Cyberax, Вы писали:
C>Я вот обращаю внимание. Точнее не внимание, у меня уже инстинкт такой — C>экономить память и процессорное время. И пользователям нравится, как ни C>странно.
А ты попробуй вместо этого фичу полезную написать, я уверен это им тоже понравится
Dyoma wrote:
> C>Я вот обращаю внимание. Точнее не внимание, у меня уже инстинкт такой — > C>экономить память и процессорное время. И пользователям нравится, как ни > C>странно. > А ты попробуй вместо этого фичу полезную написать, я уверен это им > тоже понравится
Ну так одно другому не мешает, кроме того, у меня программы может
расширяться с помощью VBA-скриптов (на которых уже написано несколько фич).
Здравствуйте, Dyoma, Вы писали:
C>>>У меня тоже гигабайт, но мне ее жалко. Пусть лучше больше памяти в кэш C>>>диска уйдет. VD>>Да тебе нужно жабу душить . D>Поставь еще один, ну хоть половину. Ты только представь сколько времени ты этим съэкономишь программерам на оптимизации.
Больше уже нельзя — слотов свободных уже нет (у меня ноут).
Здравствуйте, Cyberax, Вы писали:
>> А ты попробуй вместо этого фичу полезную написать, я уверен это им >> тоже понравится
C>Ну так одно другому не мешает, кроме того, у меня программы может C>расширяться с помощью VBA-скриптов (на которых уже написано несколько фич).
С сожалению обычно мешает. Хочешь сделать людям что-нить хорошее и упираешься в ограниченно ресурсов
Здравствуйте, eao197, Вы писали:
E>Но почему же лично я не считаю, что Java/C# совершили прорыв в смене сознания, как это сделал в свое время C++? Да потому, что C++ позволил массе реальных C-программистов применять ООП на практике. Java/C# не сделали этого, потому, что ООП уже не нужно было продвигать в массы. Все, что они сделали -- это создали новую, более эффективную (хотя это не бесспорно) технологию разработки ОО программ в духе C++. Но дальше они не пошли. Ведь что мы имеем в C++: статическая типизация; иерархия классов; объекты, которые не могут изменить свой тип (класс) в процессе жизни; передача сообщений между объектов в виде синхронного вызова методов. То же самое происходит в Java/C# с некоторыми изменениями/дополнениями (вложенные и анонимные классы в Java или делегаты в C#). Но здесь нет смены парадигмы. Понятно, что сменились некоторые приемы, где-то используется рефлекшен вместо шаблонов, где-то делегаты вместо указателей на методы. Но это не принципиально. Принципиальными изменениями, например, могли бы стать: E>- асинхронная доставка сообщений;
Тут есть большая проблема с возвращаемым значением. Но если ее решить (выбрать какое-нить решение), то такую фичу можно сделать на java (и, наверное на C#) уже существующими средствами. Тут нужено не изменения языка, а просто инструмент/библиотека.
E>- изменение иерархии классов по ходу работы программы;
Что ты имеешь ввиду? Какие задачи это позволит решить, или какие решения сделает возможными?
E>- изменение типа (класса) объекта по ходу работы программы;
На Smalltalk это возможно (средствами языка), но применяется очень редко. Как правило делигирование спасает отцов русской демократии
E>- поддержка одновременно динамической и статической типизации (причем первый шаг к этому в C# уже планируется в виде ключевого слова var (Краткий пересказ
На мой взгяд основное достоинство динамической типизации — отсутствие статической. Вообще эта идея (StrongTalk) была засунута под ковер в Sun
Но сама по себе эта фича imho ничего не изменит, просто удобная опция. Где-то тип написать, где-то a-la assertion, а где-то unit тест. Мое отношение к статической типизации — одно из средств борьбы с ошибками.
E>Если же я попробую сказать, что бы я считал прорывом в области языков программирования, то это было бы что-то в роде: E>язык, который сделал бы возможным широкое использование одной или нескольких существующих сейчас и успешно зарекомендовавших себя идей, для которых пока нет технологий.
E>Возьмем, к примеру, DSL (здесь я согласен с Re: Следующий язык программирования — 2
). Но он не смог стать популярным. Тому есть множество причин. Скажем, для меня способ написания программы в виде S-выражений не удобен (ни для написания, ни для чтения), хотя Лисп-программисты утверждают, что это не проблема. Тем не менее, факт остается фактом. Лисп показал себя не пригодным для широкого применения. А это значит, что огромная масса программистов, которые не знают Лиспа, даже не представляют себе, как же может выглядеть из приложение, написанное на нескольких DSL-ях (по своему DSL на каждом уровне абстракции). А теперь вообрази, что им дают в распоряжение такой язык и показывают, как это просто. Язык, который поддерживает DSL так же легко и естественно, как ОО-языки ООП. Вот лично ты готов сейчас представить свой текущий проект в виде всего лишь нескольких строчек на DSL верхнего уровня? Каждая из которых раскрывается в несколько строчек на DSL еще более низкого уровня, а те, в свою очередь, точно так же. И так до тех пор, пока дело не дойдет до обычного универсального языка программирования?
E>Готов? Лично я не готов.
Лично я побоялся бы применять DSL. Этот подход держит за руки еще сильнее чем водопадный процесс. Если я сделал архитектуру, потом начала ее реализовавать и тут выясняется, что есть требования несовместимые с моей архитектурой, то я вынужден развалить все преложение, сделать другую архитектуру и собрать куски под нее. А если я сделал язык, написал на нем кучу кода и тут выясняется, что это плохой язык — я останусь вообще без всего. Как будто ничего не делал вообще.
И шансов сделать плохой язык гораздо больше чем плохую архитектуру. Посмотри на существующие языки на создание которых потрачены ресурсы недоступные практически ни одному проекту. И сколько в них проблем!
E>Пока все это совсем не большие проекты. Поэтому я и не знаю, как же подобный подход будет масштабироваться на разработки, которые сейчас имеют объем в сотни тысяч строк C++, состоящие из множества уровней абстракции. Но в то, что это возможно, я верю. И думаю, что для этого смена мышления таки потребуется. Вот взгляни на возглас VladD2: Re[6]: Следующий язык программирования
. Тем не менее, то, что Владу кажется ужасом и дикостью на самом деле очень интересная и полезная фишка (при разумном использовании, естественно). И уж если Влад гордится тем, что вовремя сумел перейти на более прогрессивный C#, то кто знает, может и подобные идеи через какое-то время будут для него обыденностью.
В небольшом проекте — я за. Где "небольшой проект" это когда все выкинуть, переосмыслить и написать заново приемлимо. Но такой подход не масшабируем по определению. Готов ли я согласиться применить DSL с более мягкими ограничениями — не знаю, не приходит мне в голову более мягкое, но все еще приемлимое ограничение...
E>Теперь, вернемся к вопросу о соотношении языков и инструментов. Представь себе, что появился язык для удобного создания DSL-ей. Будут ли современные примочки типа unit-тестинга или рефакторинга востребованны в таком языке? Да безусловно. Но и они выйдут на совсем другой уровень. Представь себе unit-тестинг для семантической полноты DSL. Т.е. сейчас мы легко представляем себе unit-тест для проверки setter-ов/getter-ов. А unit-тест, который проверяет корректность одного предложения DSL (за которым может скрываться функциональность в миллионы строк C++ кода)? Или сейчас мы прекрасно представляем себе рефакторинг, который заменяет название у метода класса (с соответствующим изменением его вызова по всему проекту). А аналогичный рефакторинг для части DSL? Например, замена SQL-выражения SELECT на что-то похожее, по смыслу, но другое по написанию?
А по мне так то же самый Smalltalk (и любой другой язык, идеологически близкий к self) вполне себе удобное средство для создания других языков. Но существенная разница в том, что ошибки из области языковых идей перемещаются в область архитектурных идей, которые более приемлимы (менее фатальны). К тому же такой выход решает проблемы с инструментами — умный инструмент делать тяжело, а если он еще и не глобально применим то просто не рационально. А пытаться спроектировать очень общий — велика вероятность сделать очень бесполезный Думаю в большистве случаев можно обойтись без придумывания нового синтаксиса, вешай новую семантику на существующий и пользуйся инструментами которые его понимают.
Лишбы язык был расширяемый сам по себе. В этом отношении показательно как в язык (если он императивный) введены такие понятия как ветвление по условию, циклы. Если они выражены на том же самом языке, то скорее всего на нем можно вырозить все (или почти все) что потребуется. Если даже такие бызовые вещи введены как специальные операторы, то это говорит о его выразительной ограниченности.
E>А теперь вдумайся: миллионы программистов по всему миру начинают считать нормой DSL-парадигму, а ООП рассматривают как ассемблер, к которому в конце-концов их компилятор транслирует их программы (как Cfront с C++ текстами). Вот это я и называю сменой мышления. И языки, которые поддерживают DSL-парадигму я бы назвал "следующими языками программирования".
Все-таки ОО это не язык, это способ смотреть на задачу. Код который рожает транлятор не должен никак ни на что смотреть и видеть его в идеале тоже никто никогда не должен.
Здравствуйте, Dyoma, Вы писали:
D>С++ предлагает девелоперу думать о задаче объектами, а java + Idea/Eclipse (или C# + resharper/VS2005) предлагают девелоперу думать рефакторингами. Тут я еще раз хочу обратить внимание на то, что "думать рефакторингами" — решение не тактическое, а стратегическое. Оно предполагает изменить весь процесс разрабтки, строить архитектуру приложения не до реализации, а во время и после, опираясь на уже реализованное, на опыт полученный во время написания кода и на требования в насчтоящий момент времени.
Лично я так не думаю. Если тебе нравится относится к рефакторингу как к стратегическому направлению разработки -- ради бога.
E>>Инструмент способен существенно поднять производительность труда, но не изменить ход мысли. Киркой и лопатой ты будешь прокладывать метро под рекой 100 лет. С помощью отбойных молотков -- 25. С помощью специальных комбайнов -- 5 лет. Но ты будешь прокладывать тонель метро. Ни один из этих инструментов не подтолкнет тебя к идее сделать над рекой железнодорожный мост, на который будут выходить пути метро.
D>Есть критическая производительность, которая делает технологию возможной (применимой). Строительство метро стало популярным когда появились "специальные комбайны",
Ничего подобного. Строительство метро возникло тогда, когда появилась идея запустить общественный транспорт под землю. Если не ошибаюсь, еще в конце 19-го века. Никаких комбайнов тогда еще не было. Они появились как раз как необходимость повышения производительности труда.
D> ОО — когда появились языки с на которых можно написать класс, а не ручками клепать vtbl.
Имхо, ОО-языки появились как следствие развития идей ООП.
Имхо, ты путаешь причину со следствием.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Лично я так не думаю. Если тебе нравится относится к рефакторингу как к стратегическому направлению разработки -- ради бога.
Мы тут говорили о смене мышления. Вот тебе путь. Все есть языки, теории, средства (ксати приятно сдаланные, а не поделки на попробывать). В общем хочешь думать по другому — пожалуйста.
D>>Есть критическая производительность, которая делает технологию возможной (применимой). Строительство метро стало популярным когда появились "специальные комбайны",
E>Ничего подобного. Строительство метро возникло тогда, когда появилась идея запустить общественный транспорт под землю. Если не ошибаюсь, еще в конце 19-го века. Никаких комбайнов тогда еще не было. Они появились как раз как необходимость повышения производительности труда.
Я примерно представляю когда в Лондоне метро появилось и какие тогда были землекопательные технологии , поэтому и написал "популярно". Мне так же известны люди, которые объектный дизайн реализовывали на плоском C, но такие решения не были популярны.
D>> ОО — когда появились языки с на которых можно написать класс, а не ручками клепать vtbl.
E>Имхо, ОО-языки появились как следствие развития идей ООП.
Уже само название говорит, что так оно и было
E>Имхо, ты путаешь причину со следствием.
Нет не путаю. Причино-следственная связь с примерах с метро и ОО выглядит так:
Идея -> пробная (редкая) реализация этой идеи -> понравилось -> работаем над технологией -> есть иструмент -> теперь идея популярна.
Здравствуйте, Dyoma, Вы писали:
D>Я примерно представляю когда в Лондоне метро появилось и какие тогда были землекопательные технологии , поэтому и написал "популярно". Мне так же известны люди, которые объектный дизайн реализовывали на плоском C, но такие решения не были популярны.
Строительство метро и на тот момент было популярно. Настолько, что строилось в начале 20-го века во всех крупнейших столицах Европы, включая Москву. При тогдашнем уровне развития техники, нужно заметить.
E>>Имхо, ты путаешь причину со следствием.
D>Нет не путаю. Причино-следственная связь с примерах с метро и ОО выглядит так: D>Идея -> пробная (редкая) реализация этой идеи -> понравилось -> работаем над технологией -> есть иструмент -> теперь идея популярна.
А дальше что? После популярности?
Дальше будет следующая идея. И мое мнение в том, что прорыв будет слабо зависеть от развитости инструмента для популярных реализаций текущих идей.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ключевые слова:
E>>>Готов? Лично я не готов.
Тут нехватает еще одного: "противоречит моему опыту".
D>>Лично я побоялся бы применять DSL.
E>Вот это и значит, что по отношению к DSL нет еще смены сознания.
"Нет смены сознания" это когда говорят "я это не понимаю", а в отношении DSL я все понимаю и, где моя жизнь будет легче и где есть риски. При этом риски я считаю неоправданно большими (заметь, в крупном проекте). И мне никто не предложил пути как я могу эти риски уменьшить или как я могу решить проблему приемленой ценой.
В точности по этим же причинам, я не буду писать настольное приложение на asm. Не потому что не понимаю, не верю, неготов... Я точно знаю, что бонусы от выбора asm не стоят тех проблем в которые я вляпаюсь
E>Точно так же, как и многоуровневые DSL. Это будет уже другой способ смотреть на задачу.
Абсолютно согласен.
Здравствуйте, Dyoma, Вы писали:
E>>>>Готов? Лично я не готов. D>Тут нехватает еще одного: "противоречит моему опыту".
Моему опыту не противоречит совершенно. В моем опыте просто нет больших систем, созданных на DSL. На C++ есть. А вот на DSL -- нет. Поэтому я и не знаю, как мой текущий проект мог бы выглядеть на уровне DSL-ей. Но интересно было бы посмотреть.
D>>>Лично я побоялся бы применять DSL.
E>>Вот это и значит, что по отношению к DSL нет еще смены сознания.
D>"Нет смены сознания" это когда говорят "я это не понимаю", а в отношении DSL я все понимаю
Счасливчик, однако. Может поделишься опытом?
Я думаю, это будет не только мне интересно.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Dyoma, Вы писали:
E>>>>>Готов? Лично я не готов. D>>Тут нехватает еще одного: "противоречит моему опыту".
E>Моему опыту не противоречит совершенно. В моем опыте просто нет больших систем, созданных на DSL. На C++ есть. А вот на DSL -- нет. Поэтому я и не знаю, как мой текущий проект мог бы выглядеть на уровне DSL-ей. Но интересно было бы посмотреть.
Опыт это такая штука, которую надо апроксимировать Я тоже на 100% не уверен, что DSL принесет мне те проблемы которых я опасаюсь. И мне тоже интересно будут они или нет. Но как только речь заходит об отвественных решериях, то я на DSL не поставлю.
E>Счасливчик, однако. Может поделишься опытом? E>Я думаю, это будет не только мне интересно. Тут
я уже написал, что на мой взгяд использование DSL добавляет очень опасные (с тяжелыми последствиями) ошибки, и чем больше проект тем проще такую ошибку сделать и тяжеле последствия. Там же чуть ниже написано, что для достижения почти все благов DSL можно использовать некоторые существующие универсальные языки программирования, снижая при этом цену "DSL-ошибки". Итог: идея DSL во-первых неразумно рискованна, во вторых лишена достоинного смысла (как specific language, я ничего не имею против domain specific пристройки к существующему языку, нужен только достаточно выразительный язык и они есть).
Про какой из этих двух аспектов написать подробнее?
Здравствуйте, eao197, Вы писали:
D>>Я примерно представляю когда в Лондоне метро появилось и какие тогда были землекопательные технологии , поэтому и написал "популярно". Мне так же известны люди, которые объектный дизайн реализовывали на плоском C, но такие решения не были популярны.
E>Строительство метро и на тот момент было популярно. Настолько, что строилось в начале 20-го века во всех крупнейших столицах Европы, включая Москву. При тогдашнем уровне развития техники, нужно заметить.
Тут не соглашусь. Популярное метро это как сейчас:
1. Есть далеко не только в столицах.
2. Почти любой мой дальний маршрут (в Питере и Москве) проходит через метро.
D>>Нет не путаю. Причино-следственная связь с примерах с метро и ОО выглядит так: D>>Идея -> пробная (редкая) реализация этой идеи -> понравилось -> работаем над технологией -> есть иструмент -> теперь идея популярна.
E>А дальше что? После популярности? E>Дальше будет следующая идея. И мое мнение в том, что прорыв будет слабо зависеть от развитости инструмента для популярных реализаций текущих идей.
К сожалению нет. C-подобные языки на сегодня широко распостранены только потому что для них есть инструменты с которыми неплохо можно жить, и их идейная отсталось (сколько уже сишному синтаксису лет, а он все еще жив!) особо не мешает быть популярными
Здравствуйте, eao197, Вы писали:
E>А вот если вдуматься в твою фразу, то получается вообще странная штука: вера в то, что запуск unit-теста без ошибок что-то значит. Ты говоришь, что даже для того, чтобы узнать, запустился ли unit-тест в Boost.Test, нужно смотреть в другое место. Что уже плохо, т.к. напрягает. А ведь это твоя непосредственная работа -- убедиться, что unit-тест что-то тестирует. А для этого нужно не только добиться того, чтобы unit-тест успешно срабатывал на корректных данных, но того, что он гарантированно не срабатывал бы на заведомо некорретных данных. Поэтому лично я при написании каждого unit-теста делаю, как минимум две проверки этого теста -- на гарантированный успех, и на гарантированную неудачу. Поэтому для меня нет проблем с тем, что unit-тесты в Boost.Test в test-suite нужно прописывать явно и вручную. Ну не сложно это. Совершенно.
Я имел ввиду, что иногда код коментируют, что бы он временно не работал, естественно коментировать в двух местах — трудоголиков мало Соотвественно закоментирована будет ссылка на тест, а не сам тест...
E>И еще одна ремарка о unit-тестах. Кроме того, что unit-тесты в состоянии покрыть тестами только небольшую часть функиональности и далеко не во всех областях (например, как покрывать тестами распределенные вычислительные системы или системы реального времени), так еще и сами unit-тесты -- это программы, которые не защищенны от ошибок. Поэтому unit-тест -- это всего лишь одна из новомодных методик в старом как само программированние процессе -- тестировании и верификации программ. И поэтому я сомневаюсь, что unit-тестинг может сильно поменять способ мышления разработчика.
Unit-тесты они от слова unit, что означает единица. В случае с тестами речь о единицы функциональности имеющей самостоятельный смысл. Распределенное вычисление — это не единица функциональности, это посистема, а значит, тест который ее проверяет не unit-тест. Единицами в этом случае могут быть
-менеджер, распределяющий задачи
-политика балансировки
-сама задача
... еще что-то или другое, в зависимости от реализации...
Что ж до веривикации, то в отличии от нее unit-тестирование работает, а верификация имеет фундаментальные проблемы. И делая проект с тестами и без тестов действуешь существенно по-разному.
Здравствуйте, Dyoma, Вы писали:
E>>Моему опыту не противоречит совершенно. В моем опыте просто нет больших систем, созданных на DSL. На C++ есть. А вот на DSL -- нет. Поэтому я и не знаю, как мой текущий проект мог бы выглядеть на уровне DSL-ей. Но интересно было бы посмотреть.
D>Опыт это такая штука, которую надо апроксимировать Я тоже на 100% не уверен, что DSL принесет мне те проблемы которых я опасаюсь. И мне тоже интересно будут они или нет. Но как только речь заходит об отвественных решериях, то я на DSL не поставлю.
На ООП так же изначально не ставили. А в некоторых задачах, имхо, и сейчас ставить не разумно. Например, в вычислительных задачах (вот и Вирт о том же: Лекция Вирта в НГУ.
). Забавная критика ООП есть у Реймонда в "The Art of Unix Programming": Unix and Object-Oriented Languages.
E>>Счасливчик, однако. Может поделишься опытом? E>>Я думаю, это будет не только мне интересно. D>Тут
я уже написал, что на мой взгяд использование DSL добавляет очень опасные (с тяжелыми последствиями) ошибки, и чем больше проект тем проще такую ошибку сделать и тяжеле последствия.
Я уже читал. Согласен только на 50%. Фатальные ошибки в проектировании фатальны как при использовании ОО-архитектуры, так и при использовании DSL. То, что язык разработать сложнее, чем архитектуру -- это общие слова. В больших и сложных проектах как архитектуру, так и DSL будут проектировать не все, кому не лень. А что до ресурсов, которые требуются для создания языков, то не нужно путать универсальные языки программирования (C++, Java, C#) и специализированные DSL -- у них совершенно разные масштабы.
D> Там же чуть ниже написано, что для достижения почти все благов DSL можно использовать некоторые существующие универсальные языки программирования, снижая при этом цену "DSL-ошибки".
А ты можешь предложить встроенный DSL a-la Makefile для Java или C++? Или хотя бы Smalltalk. Как он будет выглядеть?
А внешний DSL для той же Java, который кодогенерацией преобразуется в Java -- это совсем другое дело. Во-первых, по-хорошему, он должен быть скрыт от пользователя DSL. Во-вторых, если в этот DSL потребуется вводить какие-то алгоритмические возможности (тот же if, который, как правило, оказывается нужным), то это уже будет и не число декларативный DSL (в стиле Ant) и не Java. Отсюда и проблемы с внешними DSL-ями.
D> Итог: идея DSL во-первых неразумно рискованна, во вторых лишена достоинного смысла (как specific language, я ничего не имею против domain specific пристройки к существующему языку, нужен только достаточно выразительный язык и они есть). D>Про какой из этих двух аспектов написать подробнее?
Про оба.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Dyoma, Вы писали:
D>Опять же разница в том, что foreach — языковая конструкция, ее нельзя выразить на самом C#. Как, например, собрать строку из елементов, разделенную запятимы? D>Smalltalk: D>array do: [:element | добавляем] separatedBy: [разделяем]
D>А на С#? Опять итерация и проверяем надо ли ставить разделитель?
D>Разница в том что do:separatedBy: — метод, если его нет то его можно добавить. А вот foreach separatedBy ты ни в C# ни в java не вставишь...
Здравствуйте, Dyoma, Вы писали:
D>Я имел ввиду, что иногда код коментируют, что бы он временно не работал, естественно коментировать в двух местах — трудоголиков мало Соотвественно закоментирована будет ссылка на тест, а не сам тест...
В Java бы ты комментировал метод test*. А в C++ закомментировал бы код внутри функции test*, а не весь test или ссылку на test. Получил бы то же самое, что и в Java. Здравый смысл еще никто не отменял. И не нужно решать социальные проблемы техническими средствами.
D>Unit-тесты они от слова unit, что означает единица. В случае с тестами речь о единицы функциональности имеющей самостоятельный смысл. Распределенное вычисление — это не единица функциональности, это посистема, а значит, тест который ее проверяет не unit-тест. Единицами в этом случае могут быть D>-менеджер, распределяющий задачи
А как его протестировать, если все грабли выплывают под большой нагрузкой?
D>-политика балансировки
Угу, автономно тестируемый load balancer. Который имитирует подключения к себе и прохождение трафика через себя.
D>-сама задача
Сама задача -- это множество процессов. Которые должны работать именно вместе и так, как было задумано.
Я хочу сказать, что unit-тестинг -- это всего лишь один из инструментов, с довольно ограниченной сферой применения. И ни в коем случае не must have политика на все случаи жизни.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
.
