L>>>Знаешь, я как-то об этом уже писал, но поиском не нашёл. Если вкратце, то такие вещи имхо нужно делать средствами языка. Например, в Haskell это будет функция. А типы выведет компилятор.
H>>Макросы — это и есть средство языка Мы на языке описываем его самое и получаем новый язык — чуть более удобный и богатый.
G>Вот только проблема в том что не нужно людям средство создание языка. Им нужно async\yield\do-нотация\query comprehension\type providers и прочие вещи, которые вы называете "хардкодом компилятора". Именно эти хардкоды компилятора делают язык популярным.
Ну так перечисленное сделано. И не без применения макросов (tm).
G>ЗЫ. Макросы — не средства языка, а средства компилятора языка. А то и T4 тоже средства языка получаются.
Наверно мне ключевое слово macro привиделось...
/* иЗвиНите зА неРовнЫй поЧерК */
Re[26]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я имел в виду полноценный рефакторинг. А так — да, переименование есть. Хорошо, конечно. Дело осталось за "малым" — реализовать полноценный рефакторинг а ля Решарпер. Вот только это проект на тысячи человекочасов. А пока, извините, но я не могу принять рефакторинг за плюс Немерла, ибо он в зачаточной стадии.
Ну, так сам ответь. Это принципиальная проблема (рефакторинг сделать нельзя или очень сложно) или все же чисто техническая (нужно время/ресурсы)?
А вот для динамики рефакторин сделать нельзя принципиально.
ВВ>"Доступ к компилятору" — это не только АПИ, но еще и возможность влиять на развитие языка. Были бы вы просто группой поддержки, отвечающей за интеграцию, когда поляки бы занимались развитием языка без всяких оглядок на студию, сдается мне, накушались бы вы по полной.
Ты просто не представляешь каков в компиляторе объем кода отвечающего за нужды интеграции. Это где-то 2-3 события и один вызов функции.
ВВ> Это ты вот не видишь будущее языка без ИДЕ, поэтому и фичи рассматриваются в контексте интеграции — без этого жизнь бы медом не казалось.
Да не вижу. Так же как не вижу жизнь в городе без транспорта. Но фичи я не затачиваю, а согласую.
ВВ>А представь вот как весело энтузиастам какого-нибудь OCaml ИДЕ для него делать.
Ну, потому многие и плюются с F#-а когда узнают, что файлы нужно распологать в определенном порядке, да еще и каталогов в проекте делать нельзя.
ВВ>Вывод типов как раз серьезно усложняет задачу создания полноценной ИДЕ.
Поверь тому кто этим занимается. Это не так.
ВВ>Фактически приходится выводить типы на уровне интеграции.
Не говори ерунды.
ВВ>Возможность при этом задействовать сервисы компилятора есть далеко не у всех языков.
Что же им мешает?
ВВ>Кстати, у Немерле эти сервисы были или ты их сам сделал?
В немерле испльзуется сам компилятор. Точнее его наследник в котором переопределено несколько методов. А ты думал мы так круты, что выводим типы лучше компилятора?
ВВ>К тому же ты вырезал самый важный фрагмент из моего сообщения. Нет просто "динамики". Есть конкретные языки. Задача создания ИДЕ для них обладает неодинаковым, скажем так, уровнем сложности.
Да, согласен. Вот для Эрланга, говорят, IDE вообще ненужно, а рефакторинг сводится к замене по контексту (так как все идентификаторы уникальны).
ВВ> Создание ИДЕ для Питона — это задача сложнейшая.
И для Руби тоже. А это те самые ДСЛ-ные языки.
ВВ> А я привел в пример другой язык — Pure. Функциональный, без мутабельных переменных. Для него во многих случаях реально возможен вывод типов.
Если вывод возможен, то в этих местах он уже не динамический, а статический. И конечно же все что относится к статике для него не чуждно. А там где невозможен, то для него справедливо все что говорится о динамике (в том числе и жопа с IDE).
ВВ> *Естественно* вывод типов возможен не всегда.
Не очень естественно. Давай тогда назовем языки с выводом типов динамическими? Самому то не смешно?
ВВ>Ну так в этом и смысл динамики.
В чем? Чтобы периодически иметь проблемы?
ВВ>Так где в динамике невозможен вывод типов, в статике будет просто неработающий код.
Да, ладно. Может просто будут другие подходы? Ну, там компонентный, или полиморфизм какой-нить?
ВВ>Даже если этот код в принципе корректен — тайп-чекер его не пропустит.
Во как?
ВВ>Банальный пример того, что свернет мозги немерлевскому тайп-чекеру:
ВВ>
ВВ>using system;
ВВ>out x = puts x $$ out;
ВВ>out "One" "Two" "Three" "Four" "Five";
ВВ>
Еще бы понять бы что все это значит.
VD>>Ну, реализуй. У тебя вот есть Ела. Сделй для нее IDE. Погляди что выйдет. А то пока что это все не очень ответственный треп.
ВВ>Для начала надо бы язык закончить. И таки да, у меня не ДжаваСкрипт и не Питон, мне типы выводить гораздо проще.
Ну, дерзай. Года тебе хватит?
ВВ>>>Вот какой стимул у РОР-иста переходить на nrails? Разве что ради скорости. Ну так РОР медленный потому что он тупо медленный, а не потому что динамика. V8 вон быстрее раз в сорок. VD>>Не он тупо медленный потому что тупо на медленном Руби написан и с применением тупо медленных подходов которые на Руби проще реализовать нежели быстрые.
ВВ>И с чем ты не согласен?
С твои утверждением. Он тупо медленный именно потому что реализован ну тупо медленном Руби, а не по каким-то другим причинам. Тоже самое решение но на Груви уже в несколько раз быстрее. А это тоже скрипт.
ВВ>Руби — медленный интерпретатор. Динамически-типизированный язык может быть и компилируемым. И разница в скорости будет весьма заметной.
Не весьма. Вся динамика (ради которой все и зативалось) будет такой же тупо медленной.
Более того медленность не единственный недостатко. Тупо интелисесна или тупо проверки ошибок ты тоже тупо не получишь.
ВВ>Я имел в виду, что асп-нет-чикам не надо доказывать, что статика лучше динамики.
Зато многим из них надо доказывать (казалось бы) прописные истины.
ВВ>Это другая аудитория совсем. Никто тут по динамике не сохнет по большей части. А nrails — это именно для них. В миграцию рубистов я что-то слабо верю.
Я тоже. Но вот объяснить им все куда проще будет. Это парадокс который занимает меня по хлеще чем языковые проблемы и споры статика вс. динамика. Тут я хоть понимаю предпосылки. А там...
ВВ>>>По-моему все просто. ВВ>>>А священная война в стиле "статика + вывод типов + макросы" во всем круче динамики ни к чему не приведет. VD>>А это утверждение ты только что сам придумал.
ВВ>Да нет, кто-то из ваших говорил нечто подобное. Возможно, что не ты.
Не надо на кого-то ссылаться. Есть автор темы. Есть тема.
ВВ>>>Потому что на самом деле не круче. Они разные и для разного. Как бы ни были круты макросы так или иначе вы упретесь в ограничения системы типов, которые в динамике отсутствуют как класс. VD>>Очередную чушь морозишь. Системы типов есть везде. Даже в ассемлере. А уж в динамически-типизированных языках и подавно.
ВВ>Я где-то сказал, что в динамике нет типов? Ты опять по диагонали читаешь?
Блин, супер! Кончай эти приемы. Ты утверждал, что у динамики нет "ограничения системы типов". Что чушь. Есть система типов, есть и ограничения.
VD>>Если ты утверждаешь, что система типов скажем дотнета или немерла утупает Рубийной, то потрудись это обосновать.
ВВ>Про Руби не знаю. Но вот намедни попробовал перевести такой вот код на вполне себе статически-типизированном OCaml на Немерле, и не смог:... ВВ>Впрочем, может, знаний не хватило
Не исключено.
А зачем вообще такой фигней заниматься?
ВВ>Ага. Только вот тесты все равно нужны.
Только разные и в разном объеме.
ВВ>>>Слишком много переменных, известных только в рантайме, чтобы это что-то решало. VD>>Что же тебя так тянет на откровенно высосанные из пальца утверждения? VD>>Ну, что может быть известно только в рантайме при разработке того же веб-сервера?
ВВ>Какого еще веб-сервера?
Здрасте!
VD>>Ведь ответ очевиден — только данные! А это то как раз не являются проблемой.
ВВ>Угу, а программа отвечает за преобразование данных. А так как данные относятся к числу неизвестных, то и статика идет лесом.
Да ладно! Кончай гнать то! Данные конечно неизвестны, но для их обработки нужно знать во время компиляции только их типы. А вот это то как мы знаем. Иначе вообще никакой статически-типизированный код не был бы возможен.
ВВ>Специфика веба в том, что данные эти приходят черт знает откуда.
Не имеет значения.
ВВ>И часто вообще никакого контроля над ними нет.
Это проблемы тех кто не умеет их готовить.
ВВ>К тому же половина приложения — клиент — так или иначе голимая динамика.
Не имеет значения.
ВВ> Именно голимая, на голимом ДжаваСкрипте. Поэтому ценность того, что вы там где-то в каком-то месте повысите статический контроль в целом падает, ага.
Чушь. Мы во время компиляции знаем что хотим получить от клинета. Значит можем автоматически сгенерировать код проверки корректности данных и копирования их в статически-определенные структуры. Далее работаем как всегда.
ВВ>Угу. Получаешь данные из внешнего источника и осуществляешь их разбор. Все, это динамика.
Во как? А как же наш парсер статически скомпилирвоанный все это делает?
Кончай выдумывать новую терминологию. Динамика — это кода типы определятся в рантайме. Для веб-сервера — это почти никогда не нужно. А будет нужно, на то есть компонентный и полиморфизм.
ВВ>Вылетать будешь в рантайме.
Сообщения об ошибках выдавать, если данные не соответствую спекам.
ВВ>Читаешь в своем приложении конфиг? Ага, динамика.
Чтение данных не есть динамика. Структура конфига известна заранее.
Кстати, конфиги — это одно из того, что сделано у нас на макросах. В каждом новом проекте в файлик AssemblyInfo.n у нас добавляется мета-атрибут:
Если ты во время разработки создашь такой файл (через ГУИ студии, например), то макрос увидит, что файл появился или изменился и создаст статически типизированную обертку для него.
Вот тебе и динамика! И тема как раз об этом. То что в динамике делается за счет рантайм-оверхэда, в ООП за счет неприятных приседаний, в немерле делается за счет макросов. И мы работаем всегда со статически-типизированным окружением и без приседаний.
Добавляем в ГУИ строковый ресурс, идем в код и вуаля имеем там Resources.String1. Весь из себя статически-типизированный с комплит-вордом и шлюхами.
ВВ>Работаешь с хэш-таблицами? Динамика.
Тоже чушь. Тип ключа известен. Значения тоже. То что у списков элементы можно добавлять — это тоже динамика?
ВВ>Читаешь параметры УРЛ? Динамика. Работаешь с куками? Динамика. И так далее, и тому подобное.
Короче, ты выдумал себе новое значение терминов и теперь на этом основании делаешь какие-то доказательства. Но мне это ни разу не интересно.
VD>>Вот с этим можно согласиться. Лично если я буду иметь на руках два решения одинаковых по возможностям, то я предпочту статически-типизированное просто потому, что оно будет более быстрым, комфортным и надежным. А раз мы сошлись на том, что можно достичь возможностей динамике используя связку "статика + вывод типов + макросы", то остается только создать действительно хорошую реализацию.
ВВ>Два решения? А губа не треснет? Тут одно бы найти
Нет. Я люблю выбор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, FR, Вы писали:
FR>>>В том же D доступен полноценный compile-time на довольно широком подмножестве языка http://www.digitalmars.com/d/2.0/function.html#interpretation
VD>>Не полноценный. Это, по словам же самого автора, крутой констант-фолдинг.
FR>Вообще-то тьюринг полный
Не путай тюринг-полноту и полноту возможностей. Это совсем разные вещи. Скажем С++ и его шаблоны тюринг-полны. Но С++ может читать файлы, а его шаблоны — нет.
FR>Ну и конечно вынужденно функционально чистый.
Не вынужденный, а по прихоти авторов. В немерле, вот вполне себе императивный аналог и никто не кашлеет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, FR, Вы писали:
VD>>А как, кстати, с поддержкой IDE при этом?
FR>Традиционно для окамла
А можно не уходить от ответа? Мне правда интересно.
VD>>Так же забавно сравнить размер кода. VD>>Моя реализация макры находится здесь.
FR>Тут не понял это же вроде ссылка на корень немерлевского SVN.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я имел в виду полноценный рефакторинг. А так — да, переименование есть. Хорошо, конечно. Дело осталось за "малым" — реализовать полноценный рефакторинг а ля Решарпер. Вот только это проект на тысячи человекочасов. А пока, извините, но я не могу принять рефакторинг за плюс Немерла, ибо он в зачаточной стадии.
Покажи мне рефакторинг уровня немерла для динамически типизированного языка.
JetBrains PyCharm "IDE" для питона в плане рефакторинга сливает немерлу.
ВВ>"Доступ к компилятору" — это не только АПИ, но еще и возможность влиять на развитие языка. Были бы вы просто группой поддержки, отвечающей за интеграцию, когда поляки бы занимались развитием языка без всяких оглядок на студию, сдается мне, накушались бы вы по полной. Это ты вот не видишь будущее языка без ИДЕ, поэтому и фичи рассматриваются в контексте интеграции — без этого жизнь бы медом не казалось.
Повторю еще раз: Мелкософт режет фичи для C# на основании "трудно поддержить в IDE".
ВВ>Вывод типов как раз серьезно усложняет задачу создания полноценной ИДЕ. Фактически приходится выводить типы на уровне интеграции. Возможность при этом задействовать сервисы компилятора есть далеко не у всех языков.
Их нет только у тех то об этом не задумывался.
ВВ>Банальный пример того, что свернет мозги немерлевскому тайп-чекеру: ВВ>
ВВ>using system;
ВВ>out x = puts x $$ out;
ВВ>out "One" "Two" "Three" "Four" "Five";
ВВ>
Немерле не поддерживает рекурсивные типы. И что?
Думаешь большая проблема их поддержать?
ВВ>Я повторю — да, в динамике интеллисенс будет работать не всегда. Но там, где он не будет работать, в статике код вообще не будет работать.
И правильно. Нефиг код с ошибками пытаться выполнять.
ВВ>Для начала надо бы язык закончить. И таки да, у меня не ДжаваСкрипт и не Питон, мне типы выводить гораздо проще.
А из-за чего тебе типы выводить проще?
Может из-за того что у тебя метапрограммирования нет?
ВВ>И с чем ты не согласен? Руби — медленный интерпретатор. Динамически-типизированный язык может быть и компилируемым. И разница в скорости будет весьма заметной.
Компиляция динамике нихрена не помогает.
Не смотря на всю свою круть V8 тормоз и жрет память тоннами на ровном месте.
Ибо ему приходится на лету классы объектов менять и на каждый чих новый тип создавать.
ВВ>Ага. Только вот тесты все равно нужны.
Функциональные ониже регрессионные. И делаются они по мере нахождения багов.
ВВ>Угу, а программа отвечает за преобразование данных. А так как данные относятся к числу неизвестных, то и статика идет лесом.
Что за бред?
Какое отношение валидация пользовательского ввода имеет к типизации?
ВВ>Специфика веба в том, что данные эти приходят черт знает откуда. И часто вообще никакого контроля над ними нет.
Это как?
Я что в своем собственном приложении не могу контролировать свои собственные данные?
ВВ>К тому же половина приложения — клиент — так или иначе голимая динамика. Именно голимая, на голимом ДжаваСкрипте. Поэтому ценность того, что вы там где-то в каком-то месте повысите статический контроль в целом падает, ага.
Вот только этот жабаскрипт можно генерировать.
Причем за основу исходного кода можно взять реактивное программирование и зарулить императивный жабаскрипт в глубокие минуса.
Ага? http://www.impredicative.com/ur/
ВВ>Угу. Получаешь данные из внешнего источника и осуществляешь их разбор. Все, это динамика. Вылетать будешь в рантайме. Читаешь в своем приложении конфиг? Ага, динамика. Работаешь с хэш-таблицами? Динамика. Читаешь параметры УРЛ? Динамика. Работаешь с куками? Динамика. И так далее, и тому подобное.
Написал if динамика... ой трололо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, gandjustas, Вы писали:
G>Что-то тебя понесло. Под "динамикой" обычно понимают что тип выражения определяется в runtime. G>Как это соотносится с твоим утверждением что парсер xml, который есть функция String -> Some XDocument, является динамикой?
Да он просто понял что в очередной раз с треском слил и начал спамить кучу постов основанных на полностью искажонном смысле общепринятых терминов.
Он всегда так делает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Мое утверждение — и при использовании внешних ДСЛ-ей и при использовании макросов результат обладает сравнимым уровнем юзабилити. ВВ>Опровергай.
Это очевидный бред для любого кто имел дело например с макросом PegGrammar и любым внешним генератором парсеров.
Или вот например http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.Xml/Test/Main.n
Попробуй повторить внешним ДСЛ.
ВВ>Ну и не разговаривай. Я ж тебя за язык не тянул, а сколько постов мне накатал. Не, я понимаю, конечно. "В интернете кто-то не прав".
Если ложь не опровергать то кто-то может поверить.
ВВ>Ой, ради бога. Эта проблема называется — нанять ли одну снегоуборочную машину или сорок таджиков с лопатами. У контор типа МС вообще обычно второй способ работает. И недостатков ресурсов у них тоже как-то нет. Поэтому да — заботиться о том, насколько им там сложно со своими ДСЛ-ями возиться мне совершенно не хочется.
И получается очередной говнопродукт.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
L>>>>Знаешь, я как-то об этом уже писал, но поиском не нашёл. Если вкратце, то такие вещи имхо нужно делать средствами языка. Например, в Haskell это будет функция. А типы выведет компилятор.
H>>>Макросы — это и есть средство языка Мы на языке описываем его самое и получаем новый язык — чуть более удобный и богатый.
G>>Вот только проблема в том что не нужно людям средство создание языка. Им нужно async\yield\do-нотация\query comprehension\type providers и прочие вещи, которые вы называете "хардкодом компилятора". Именно эти хардкоды компилятора делают язык популярным.
H>Ну так перечисленное сделано. И не без применения макросов (tm).
Точно? И type providers? И async как в 5-ом шарпе? А yield разве не через тот самый "хардкод компилятора" реализован?
Re[19]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Динамика ничем не поможет. Сам сценарий изначально — это динамика. Чтение ХМЛ через XmlReader — это динамика. Работа с базой — это динамика. Динамика — это просто данность. Тут другой вопрос — чем в данном случае поможет статика?
Извини, но это ерунда. Реляционки это в большинстве задач никакая не динамика, как и xml приходящий от известного сервиса. Нету там динамики, там все должно быть в том состоянии на которое рассчитан код, либо корректная работа программы не может быть гарантирована. Все это спокойно контролирует система типов. Просто не надо ей мешать.
ВВ>Да ну, не так страшен черт. Что вы так боитесь этих тестов-то? Меняются готовые тесты вообще довольно редко. Чаще пишутся новые. Сделал фичу — парочку-другую тестов для нее. Это уже до автоматизма доходит. Времени всего ничего. Зато доходит чуть ли не до 100% coverage.
Не работает это все для быстрого прототипирования. В РОР я пишу миграцию с количеством строк равным нужному мне количеству атрибутов и через пару секунд могу работать со вновь созданным в базе объектом. А ты что рекламируешь? Создай таблицу, создай 4(!!!) хранимки которые будут что-то там контролировать, создай тесты на эти хранимки, которые будут контроллировать сами хранимки и работай потом с этими хранимками через GetReader, ибо динамика и нет разницы какой DAL юзать. При всем этом тотальном контроле у тебя это все все равно остается динамикой, которая вечно разваливается, т.к. контроллируется тестами вместо компилятора.
Статика и динамика тут не при чем. Естественно никакого выигрыша в данном случае от статики ты не получишь, но это не проблемы статики.
ВВ>Причем тут ГУИ? Я говорю — вся логика пишется на клиенте. *Вся логика*. Кроме той, которую просто чисто физически нельзя писать на клиенте. Практически любое приложение можно так написать.
Кроме web, хреновое приложение получится. Начиная от безопасности, кончая урлами.
ВВ>>>А что непонятно-то Простые изолированные тесты, которые в первую очередь проверяют консистентность модели. Ну или корректность работы процедур, если они имеются. Скажем, один тест проверяет все процедуры для работы с конкретной сущностью — вставил, прочитал, сверил результаты, удалил. Z>>Зачем проверять консистентность модели которая впрямую отображает БД и зачем нужны процедуры которые делают CRUD?
ВВ>Чтобы убедиться в том, что нет рассинхрона.
Чего с чем? Процедур со схемой? Или процедур с кодом? Ты внес еще один слой возможного рассинхрона и тут же счастливо отрапортовал, что рассинхрона не будет, потому, что есть протестированый спец слой который это гарантирует.
Z>>При этом их еще и тестировать надо? В каком сценарии нам эти процедуры и тесты полезны будут?
ВВ>В основном regression testing. Собственно, один из основных смыслов юнит-тестов.
Я просил конкретный сценарий, в котором нам помогут твои сотни тестов, которые очень легко писать. Ты почему-то предпочел отделаться общими фразами. Еще раз, напиши конкретный сценарий которые оправдывает все трудозатраты которые внес в проект созданием хранимок и их тестированием.
Вобщем сделать из статики динамику действительно не так сложно, достаточно побольше хранимок, рефлекшена и работы с xml по строковым константам. Только это никакого отношения к теме не имеет, я говорю про перенос достоинств динамики в статику, а ты переносишь недостатки.
Re[20]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, Кэр, Вы писали:
Z>>А что, можно проектировать иерархию классов не задумываясь об SRP, LSP и прочих P? Это такая простая задача не наделать конфликтов с этими не вполне формальными принципами? Что, там нет ситуаций, когда все компилируется, а для исправления ошибки нужен редизайн иерархии либо костыли в виде навешиваний нескольких параллельных иерархий визиторов?
Кэр>Эти проблемы имеют меньшую стоимость разрешения. Хотя бы потому что они гораздо лучше изучены. Но я так понимаю, я тут уперся в секту, поэтому я лучше отойду в сторону.
Меньшую чем что? Повторяю, я говорил, о том, что иерархию классов проектировать по науке тоже очень не просто, однако нет ни одного программиста на ООП не спроектировавшего хотя бы парочку. На МП тоже мало программистов попробоваших свой синтаксис, проблемы абсолютно похожие. В сторону пожалуйста, видно, что по делу сказать нечего, только не надо пытаться сохранить лицо и делать из меня сектанта.
Z>>Все библиотеки вещь в себе и никакой другой задачи кроме предоставления своего функционала не решают, это раз.
Кэр>Нет. Большинство библиотек как раз-таки не изолированы должном образом от бизнес-задачи и проекта, в котором они написаны. Поэтому их как раз с трудом можно перенести в новый проект. Библиотеки из фреймворков — они как раз отличаются тем, что изначально затачиваются на многоразовое использование и допускают, что там будет бюджет на различные красивости, чтобы выделится на фоне других фреймворков.
Что сказать-то хотели? Обсудить ваше понимание отличий фреймворка от библиотеки, спасибо, не надо.
Z>>Кастомный синтаксис это всего лишь один из многочисленных способов применения метапрограммирования и он широко используется во всех языках с поддержкой метапрограммирования, это два.
Кэр>Вот против этого широкого использования кастомного синтаксиса я как раз и выступаю. Он приносит дополнительные сложности, а инструментов, что бороться с этими сложностями что-то не видно.
Сложности надо озвучить сначала. Я пока услышал только про конфликты с ключевыми словами, но это совсем детская и легко выявляемая ошибка писателя синтаксиса. В этом нет проблемы, проверьте.
Z>>Это не доказательства по аналогии, это пример вполне здравых рассуждений доказывающих ненужность конкретной технологии. Хотел обратить внимание на то, что все эти утверждения были абсолютно верны, логичны и обоснованы. Тем не менее не так страшен черт, IDE сделали, грабли научились аккуратно обходить.
Кэр>Вы здесь приводите исторический пример, затем заменяете одну технологию другой по аналогии и утверждаете, что пример остается валидным. Таким образом можно доказывать необходимость изучения любой новой технологии, которая сейчас не имеет поддержку IDE, но если хорошо вложится — то она появится. Если вы не понимаете, что это доказательство по аналогии — я лучше пойду.
Выделенное это ваши фантазии. Не надо мне их приписывать.
Кэр>Я всего лишь изложил то, что я вижу вокруг. Кастомный синтаксис в прикладных задачах — можно встретить очень и очень редко. И на это есть объективные причины, которые я изложил from the top of my head. Кэр>А у вас сразу пошли обиды — мол я "эталон", и свое "неприятие распространяю на всех".
Эталон это не от обиды, вы уж простите, это оттого, что после изложения содержимого топа вашего хеда вы делаете вывод — "никому не нужен". Такие выводы делают люди которые считают себя эталоном, нравится вам это или нет.
Кэр>Вы меня лично еще обвините, что я не ценю работу немерлистов и лично торможу прогресс программирования в целом. И типичная картина разработчика компилятора Немерле будет завершена.
Снова фантазии, завязывайте, право.
Re[19]: Веб и динамика? Веб и статика+метапрограммирование.
Z>Меньшую чем что? Повторяю, я говорил, о том, что иерархию классов проектировать по науке тоже очень не просто, однако нет ни одного программиста на ООП не спроектировавшего хотя бы парочку. На МП тоже мало программистов попробоваших свой синтаксис, проблемы абсолютно похожие.
ошибки в иерархии классов ни к чему страшному не приводят.
в худшем случае уменьшается время разработки.
ошибки в навороченном МП — приводят к полной неработоспособности программы и невозможности разработчика в этой проблеме разобраться.
Re[21]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, DarkGray, Вы писали:
DG>ошибки в иерархии классов ни к чему страшному не приводят. DG>в худшем случае уменьшается время разработки.
Нет. Они приводят к полному переписыванию программы.
DG>ошибки в навороченном МП — приводят к полной неработоспособности программы и невозможности разработчика в этой проблеме разобраться.
Простите не поверю.
Ибо моя практика говорит что ничего подобного нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, DarkGray, Вы писали:
H>>А теперь примеры некомбинируемых макросов в студию. А также вменяемые юзкейзы их комбинации.
DG>макрос распараллеливания кода может конфликтовать с linq2sql.
DG>т.к. и тот и другой — хочет select/where заменить на свою конструкцию.
Не будет макрос распараллеливания работать с select where, а будет с Select(this IEnumerable src, ..), это не проблема.
DG>но этот конфликт решается просто: что макрос распараллеливания должен работать всегда после linq2sql, в других задачах — такой явной зависимости может не быть.
Нет, этот конфликт просто от незнания простых приемов работы с макросами.
DG>зы DG>причем дьявол в мелочах.
Ага, самые страшные из них в те, которые только в нашей голове. Например мелкие случайные заблуждения человек может носить всю жизнь, даже находить им отличные обоснования, основаные на тех же самых заблуждениях.
DG>например, распараллеливание + linq2sql может дохнуть в итоге на том, что база технически или по лицензии поддерживает лишь ограниченное кол-во соединений.
Никто не будет делать распараллеливание linq2sql просто потому, что это а) это не паралелится так просто, ибо одна транзакция не параллелится, б) все что нужно сервер распаралелит гороаздо лучше, его для этого и писали.
DG>соответственно макрос параллеливания может потребоваться учить, чтобы он по разному обрабатывал код с linq и без linq
Re[6]: Веб и динамика? Веб и статика+метапрограммирование.
Справедливости ради надо отметить, что кода у Влада меньше, а возможностей больше. Кроме встраивания xml в произвольное место (как умеет и htcaml), в немеловом варианте есть if и foreach, позволяющие вставлять тег по условию или множить его в цикле.
Re[23]: Веб и динамика? Веб и статика+метапрограммирование.
DG>>т.к. и тот и другой — хочет select/where заменить на свою конструкцию.
Z>Не будет макрос распараллеливания работать с select where, а будет с Select(this IEnumerable src, ..), это не проблема.
так и linq2sql работает с Select(this IEnumerable src, ...)
DG>>но этот конфликт решается просто: что макрос распараллеливания должен работать всегда после linq2sql, в других задачах — такой явной зависимости может не быть.
Z>Нет, этот конфликт просто от незнания простых приемов работы с макросами.
bla-bla.. я самый умный, все остальные тупее меня...
DG>>например, распараллеливание + linq2sql может дохнуть в итоге на том, что база технически или по лицензии поддерживает лишь ограниченное кол-во соединений.
Z>Никто не будет делать распараллеливание linq2sql просто потому, что это а) это не паралелится так просто, ибо одна транзакция не параллелится, б) все что нужно сервер распаралелит гороаздо лучше, его для этого и писали.
опять считаешь других тупее тебя... либо сам не понимаешь о чем идет речь.
вот этот код успешно параллелится, но может сдохнуть в runtime если у базы ограниченное кол-во подключений.
при этом параллельная версия будет работать в два раза быстрее (если считать что время выполнения запросов сравнимое)
parallel
(
var managers = db.Managers.Where(manager=>manager.IsTopManager).ToArray();
var cars = db.Cars.Where(car=>car.IsFree).ToArray();
return НазначитьМашиныДляМенеджеров(managers, cars);
)
зы
вместо parallel здесь также можно применить замену синхронных запросов на асинхронные, объедиение запросов и т.д.
Re[22]: Веб и динамика? Веб и статика+метапрограммирование.
