Здравствуйте, vdimas, Вы писали:
V>Универсальный язык не может быть хорошим для всех задач, он будет одинаково посредственнен.
Эта фраза имеет смысл только если подразумевать, что этот самый универсальный язык — это язык общего назначения, а те языки что лучше — это специализированные языки (т.е. не общего назначения). Иначе таки, нет — универсальный язык таки может быть лучше для всех задач чет другой универсальный язык.
Единственное что еще приходит на ум — это намеренное использование более низкоуровневых языков с целью оптимизации производитльности.
V>А как же популярность Явы?
А что в Яве нет дженириков или она вообще не изменялась за время существования?
Ява 1.0 действительно мало для чего серьезного пригодна.
V>Мы когда смотрели ее спецификации в 95-м, тоже ухахатывались, за животы держались.. а оно вон как вышло, кто бы мог подумать.
А ты сравни эту спецификацию со спецификацией современной. К тому же в лагере явы тоже не стоят на месте. Там уже есть такие языки как Clojur, Groovy и конечно же Scala!
V>Именно, только в конце приписать надо "для каждой конкретной задачи". Чем более специализирован язык, тем он проще и тем сложнее ошибиться программисту.
Я не пойму, теперь стало модно строить свою "логику" на подмене понятий? Специализированный язык есть специализированный язык. Они не устраняют необходимость в наличии языков программирования общего назначения.
По твоему, скажем, F# более специализированный нежели C#? Или как понять твои слова?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IB, Вы писали:
ВВ>>AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо. IB>Чем слабо? Тем что там нет ПМ? =) Понимаешь, сама по себе трансформация — тоже не конечная цель, и в какой-то момент задача начнет идеально вписываться в ОО и совсем коряво в ФП. И что делать?
Отличный пример, кстати!
С одной стороны ты не прав. Таки да, АСТ удобнее описывать с помощью Алгебраических Типов Данных.
Но вот сам код лексера, парсера, типизатора и генератора кода удобнее оформить в виде тех самых классов. И было бы крайне глупо из-за этого писать компилятор на двух ЯПОН.
Посему таки ты прав, в том, что намного лучше было бы включить нужные людям возможности в язык которым они предпочитают (по тем или иным причинам) использовать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
ВВ>>Мне в большей половине этих этюдов хочется увидеть ошибку, а не результат в стиле "никогда не догадаешься, какой метод вызовется".
V>Вот именно, из детерминированного и элегантного языка превращается в непонятно что.
Во как? Где это тут что-то куда-то превращается?
Это исходный дизайн языка. Никто не виноват, что пока не пришел Ников ни не прочел стандарт языка с пристрастием и не выявил такие вот неочевидности, никто из нас не их не замечал.
Скажем, проблемы перегрузки и переопределения методов — это проблемы принятых еще в C# 1.0 решений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Для паттерн матчинга недостаточно завести одну новую конструкцию языка, для удобного его использования нужны еще конструкции, типа placeholder '_', а это не так просто в плане совместимости с имеющимся кодом
Это как раз ерунда. Куда сложнее с тем, что для полноценного PM нужны discriminated unions. А это уже сильное нелокальное изменение языка. Для чего нужна глобальная маркетологическая идея. Так что, ИМХО, не в этой жизни.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
VD>>С одной стороны ты не прав. Таки да, АСТ удобнее описывать с помощью Алгебраических Типов Данных.
AVK>Алгебраический тип данных и ПМ сами по себе ортогональны ФП. Другое дело что в ФП без них вилы, а вот в ООП как то жить можно.
ФП без них тоже прекрасно переживает. В лиспе, например, такого средтва в языке нет. Правда есть макросы делающие пожожее, но они не являются распространненым явлением и появились относительно недавно. Так что ПМ имеет то отношение к ФП, что родился в нем и под влиянием тех научных работ которые делались в рамках проектов развития ФП.
Ну, и то что ПМ не является неотъемлемой частью ФП никак не умаляет полезности этой фичи в конкретном языке. Так что, если язык не поддерживает ПМ, то делать на нем компиляторы существенно сложнее нежели на языке поддерживающем эту фичу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> В лиспе, например, такого средтва в языке нет.
Ну, с Лиспом отдельный разговор.
VD>Ну, и то что ПМ не является неотъемлемой частью ФП никак не умаляет полезности этой фичи в конкретном языке.
Конечно нет. Я про другое — ПМ + discriminated unions, если отбросить исторические корни, можно с равным правом отнести кака к ООП, так и к ФП, и совершенно непонятно, почему в ФП языках он уместен, а в ООП уже лишний.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Это как раз ерунда. Куда сложнее с тем, что для полноценного PM нужны discriminated unions.
"discriminated unions" — это локальный для ML-я псевдоним для алгебраический типов данных.
AVK>А это уже сильное нелокальное изменение языка. Для чего нужна глобальная маркетологическая идея. Так что, ИМХО, не в этой жизни.
ПМ возможен и для классов. Дорабатывать язык конечно придется, но не так чтобы очень сильно.
К примеру, Nemerle позволяет осуществлять ПМ по обычным классам даже если они описаны в другой сборке, на другом языке. При этом синтаксис получается несколько более рыхлым. Для идеального синтаксиса классы требуется размечать специальным образом (чтобы дать компилятору информацию о том какие из полей или свойств нужно использовать для идентификации значения объекта).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну, с Лиспом отдельный разговор.
Это с какой это стати? Лисп — прародитель всех ФЯ. Функциональный по духу и по букве. Если честно, то лисп
VD>>Ну, и то что ПМ не является неотъемлемой частью ФП никак не умаляет полезности этой фичи в конкретном языке.
AVK>Конечно нет. Я про другое — ПМ + discriminated unions, если отбросить исторические корни, можно с равным правом отнести кака к ООП, так и к ФП, и совершенно непонятно, почему в ФП языках он уместен, а в ООП уже лишний.
Это миф который сложился исторически. Разработан ПМ был в ФЯ и пол влиянием мат. моделей вытекающих из ФЯ, вот многие и считают ПМ чисто функциональной фичей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Причем тут конкатенация строк? Для "простых запросов" и маленьких проектов вообще говоря пофиг как там базу писать. Для чего-то посложнее оказывается, что решение на Линке не масштабируется совершенно. И зачем он нужен, когда есть специально обученный человек, который пишет базу? Заставлять его на си-шарпе писать?
Производительность человека, пишущего на стороне базы, до десяти и более раз ниже производительности хорошего программиста на дотнете, если в строках считать усредненно за некий довольно большой период. И не зря. Нету еще пока адекватного инструментария для разработки на стороне ДБ, и непонятно, когда появится. Там с рефакторингом дела обстоят не ахти, чуть возникает надобность по-другому пораскидать данные — и хана всему. Я уже молчу про отсутствие дополнительного контроля типов и о принципиальной сложности покрытия кода в БД тестами (в сравнении с тем, как обстоят дела в дотнете). В общем, разработка внутри БД на сегодня непроизводительна и принципиально ненадежна. Процедура будет содержать грабли, которые вы фиг когда тестами найдете, но у заказчика на реальных данных посыпятся ошибки конвертации данных.
И насчет масштабируемости, можно подробнее? Это раньше, в эпоху медленных компьютеров, пытались сэкономить на парсинге/предобработке запроса SQL, поэтому пихали все подряд в процедуры, а сейчас-то зачем? ИМХО, сейчас имеет смысл пихать только те задачи, которые не представимы в SQL-запросе (вопрос "представимости", кстати, от умений разработчика зависит), но для результата требуют обработать большую кучу данных, не нужных клиенту. Даже в этом случае, удобнее будет все эти алгоритмы поотлаживать на дотнете, и перенести в базу уже готовые решения.
ВВ>Вот и оказывается, что область применения linq2 весьма ограниченна.
Извини, но звучит как очередное задвигание про "черное и белое", серьезную/несерьезную разработку и прочие лозунги. Даже в "серьезной" разработке до 90% задач и более обычно примитивны и подходящи для исполнения подручными ср-вами, типа линка.
Здравствуйте, VladD2, Вы писали:
VD>Не стоит строить логику на подмене понятий. Использование разных ДСЛ-ей и использование разных языков программирования общего назначения (ЯПОН) — это очень разные вещи.
Почему? Может, от того и проблема?
VD>Кроме того, ДСЛ-и удобны, в основном, когда они встроены в какой-то базовый ЯПОН.
Не совсем, очень часто DSL пишут как сильно урезанную версию какого-нить языка, т.е. задача состоит не только хелперов для задачи понаделать, но и ограничить возможности инструмента, не относящиеся к задаче.
VD>Ты же призываешь к усугублению ситуации — консервации развития ЯПОН и использовании кучи маломощных ЯПОН вместо одного более мощного.
Как раз-таки в своей специализированной задаче DSL вовсе не "маломощный", собсно, затем он и нужен, чтобы предоставить "мощные" ср-ва для решения конкретной задачи.
VD>Не удивительно, что с тобой не соглашаются многие (если не большая часть) разработчиков высокой квалификации.
Нууу... с позиции активного пользователя языка с развитой макросистемой, ты конечно можешь себе позволить поострить. Но в ситуации, когда никто разрешение на использование Nemerle не даст, даже для разработки внутреннего инструментария, приходится пользовать DSL. Спросишь, кого интересует, на чем пишутся внутренние тулзы? Интересует заказчика, если он заказывает разработку, с условием передачи всех относящихся к ней исходников (очень популярный сценарий в заказной разработке). Он примет C/C++/Java/C#/JavaScript/XML и остальные распространенные вещи, а про существование N он даже не в курсе.
Здравствуйте, IB, Вы писали:
V>>Ведь платформа именно для того и создавалась, чтобы разработчики не парились по поводу использования разных инструментов в одном проекте. IB>Создавалась она может быть и для этого, но использовать ее в этом качестве пока не получается и я не вижу как это вообще может получиться на практике, а не в красивых теориях.
Могу лишь предположить, что у тебя узкоспециализированные задачи, раз не было подобного опыта. Мне приходилось завязывать C++/CLI — для нормальной интеграции C++ных библиотек, C# для основного кода, VB.Net — идеален для задач автоматизации офиса (кто делает это в C#, у того или задачи по офису микроскопические, или нуб, без обид ). Если еще вспомнить, что в .Net интероперабельность с COM тоже "как родная", то иногда обхожусь без C++/CLI, ибо последний требует включать в click-once MS VC рантайм, что можно избежать в случае COM.
V>>Универсальный язык не может быть хорошим для всех задач, он будет одинаково посредственнен. IB>Проблема в том, что неуниверсальный язык — непригоден вообще.
IDL непригоден? JavaScript, ShellScript, XSLT, ASN.1? Свой domain-specific конфиг на JSON непригоден? Будем считать — погорячился.
IB>Вот-вот, Ява намного удобнее C++,
Ява удобнее только наличием GC, во всем остальном она достигла уровня не далее Objective C, тут даже смешно c C++ сравнивать.
IB>однако как только в C# появились генерики и парочка других вкусностей,
Да, генерики, делегаты и yield — это мегафичи, но это мы что-то пошли в сторону... в которой бывали уже раз сто.
IB>Угу. Вернемся к тому, что есть у меня конкретная задача и часть задачи удобно решать на ООП, а часть ФП, какой язык тут удобен? Ну вот например, есть у меня отличное дерево объектов в C#, но засада — для правильного и красивого вызова нужного метода у нужного экземпляра отлично подошел бы ПМ. IB>Твои действия: IB>- Городить визитор ? IB>- Писать на F# функцию ресолвинга ? IB>- Ручное выпиливание по тайпкастам ифам и свичам ?
Скажу так, нормально делать сборки "миниатюрного" размера, тогда пофиг, на чем было написано это дерево, и каким языком ты его будешь обрабатывать. Миниатюрность сборок очень хорошо ведет себя при постоянном обновлении, через тот же click-once, закачивая каждый раз лишь минимум, и не раздражая клиента при запуске.
V>>Чем более специализирован язык, тем он проще и тем сложнее ошибиться программисту. IB>Я не вижу практической пользы от заточки языка исключительно на ООП или ФП. И практика показывает, что ни один чистый ООП или ФП язык не оказался пригодным для решения большинства типичных задачь.
Да ладно, до Явы и дотнета были Дельфи и VB/VBA, которые по количеству приложений на них затыкали всех за пояс (VB у них, Дельфи у нас). Это же были основные инструменты для бизнес-приложений. Эти и несколько других, долгое время тоже весьма популярных, типа FoxPro, 1С и т.д. тоже не особо ФП похвастать могут. Так что и тут ты погорячился.
Да, среда .Net избавила от опасности неверной реинтерпретации памятию, от ее утечки и т.д. И эти бенефиты конечно крутые, но только в сравнении с нативными "универсалами", типа С/С++. И это все равно не повысило надежность программ на C# до уровня программам на VB, FoxPro, 1C автоматически. Программы на C# до сих пор сыпятся как семечки, достаточно пройтись по тому же codeproject. Видел ли ты хоть раз, чтобы так же сыпались программы на вышеупомянутой тройке? То-то...
Мне тут очевидно только одно, универсальный мощный язык — это отличный инструмент в ручках отличного программиста... Но тысячи страниц ТЗ бизнес-системы ты тоже посадишь лопатить отличных программистов? Или может, стоит посадить специалистов в предметной области и дать им соответствующий инструментарий?
IB>Вернемся к предыдущему примеру — мне очевидно, надеюсь и тебе тоже, что при наличии ПМ в C#, данная задача решалась бы существенно проще, и с меньшей вероятностью совершить ошибку, чем любая из доступных сейчас альтернатив.
Тебе надо матчить внутри кода дерева, или некий внешний код должен матчить? Если внешний, то однофигственно, и ты пока ничего "очевидного" не показал. Мне пока очевидно, что если речь не идет об internal членах этого дерева, что разницы нет, из нашей сборки мы его вызываем, или из другой, с использованием другого языка.
Здравствуйте, IB, Вы писали:
ВВ>>AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо. IB>Чем слабо? Тем что там нет ПМ? =) Понимаешь, сама по себе трансформация — тоже не конечная цель, и в какой-то момент задача начнет идеально вписываться в ОО и совсем коряво в ФП.
Какие глупости пишешь...
AST — это идеальная задача для алгебраических типов данных, которые ты эмулируешь иерархией наследования в ООП (точно так же, как реализованы алгебраические типы в Nemerle, только тут ты "ручками"). Понимаешь, случай с AST как раз тот самый, когда соверешенно не получается породить гомоморфную иерархию, и мадам Лисков идет таким лесом, что дальше просто не куда... а значит о чистом ООП можно даже не заикаться. Не, постараться конечно можно.. но мозги закипят, и будет результат негибок и не особо расширяем. Здесь такой ООП-инструмент как наследование ты используешь именно как отдельный инструмент, за неимением другого, в отрыве от ООП-"парадигмы".
Сам по себе матчинг по типам (!!!) противен духу ООП (а только по значениям это будет недоматчинг). На уроках по ООП за это ставят двойки, поэтому не все так просто и поэтому не так просто внести в чистую ООП-среду ФП заморочки. Первоначально сделали ОГРОМНУЮ ошибку, повторив ее за Java, впечатав ООП в саму платформу, а не отдав на откуп языкам. Мы тут обсуждали несколько лет назад, если помнишь, почему бы в C# не сделать конструкцию, типа switch, но не по значениям, а по типам. Ты хоть представляешь, что сделал бы с Хейлсбергом научный мир IT за такие фокусы? Да разорвал бы как тузик грелку, опустил бы ниже плинтуса.
В каждой методологии есть свои практики, которые позволяют писать достаточно надежные программы. Смешение практик приведет только к ухудшению надежности, в этом плане thesz категорически прав. Или же, (а почему бы и нет?) настало время для выработки новых практик для этой сборной солянки... В любом случае должно пройти достаточное время, больше чем кажется, ибо даже пока научных работ на эту тему не видно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IB, Вы писали:
ВВ>>>AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо. IB>>Чем слабо? Тем что там нет ПМ? =) Понимаешь, сама по себе трансформация — тоже не конечная цель, и в какой-то момент задача начнет идеально вписываться в ОО и совсем коряво в ФП. И что делать?
VD>Отличный пример, кстати!
VD>С одной стороны ты не прав. Таки да, АСТ удобнее описывать с помощью Алгебраических Типов Данных. VD>Но вот сам код лексера, парсера, типизатора и генератора кода удобнее оформить в виде тех самых классов.
Вот и нет:
— лексер удобнее всего табличный на голом С, полученный из регулярной грамматики (не та, что перловая, а та, что класс грамматик);
— парсер комбинаторный на любом ФП с обобщенными типами и явными их инстанциированиями;
— типизатор — однозначно логический, на прологе или чем-то похожем, ибо задача из области баз знаний и поиска решений (взаимно-рекурсивные альфа/бета редукции);
— генератор кода — некий язык трансформации, желательно декларативный, возможно сам язык написанный опять же на прологе (ближе всего получается).
А в виде классов, или глобальный ф-ий или последовательности слов — вообще непринципиально.
VD>И было бы крайне глупо из-за этого писать компилятор на двух ЯПОН.
Я пять насчитал. На двух действительно глупо.
VD>Посему таки ты прав, в том, что намного лучше было бы включить нужные людям возможности в язык которым они предпочитают (по тем или иным причинам) использовать.
Ну... осталось вам написать для Немерле библиотеку генерации табличных сканеров по регулярным выражениям + пролог машину + научиться ей пользоваться + написать язык трансформации данных на основе этой пролог-машины и тогда согласен, достаточно будет одного языка.
Здравствуйте, vdimas, Вы писали:
VD>>Не стоит строить логику на подмене понятий. Использование разных ДСЛ-ей и использование разных языков программирования общего назначения (ЯПОН) — это очень разные вещи.
V>Почему? Может, от того и проблема?
Разберись, напиши статью.
V>Не совсем, очень часто DSL пишут как сильно урезанную версию какого-нить языка, т.е. задача состоит не только хелперов для задачи понаделать, но и ограничить возможности инструмента, не относящиеся к задаче.
В тебя какое-то свое определение ДСЛ-ей. ДСЛ — это язык прикладной области, а не ограниченый ЯПОН. Может от того ты и споры эти разводишь...
V> V>Как раз-таки в своей специализированной задаче DSL вовсе не "маломощный", собсно, затем он и нужен, чтобы предоставить "мощные" ср-ва для решения конкретной задачи.
Про ДСЛи я уже говорил. Иди прочти определение этого термина и сравни его с определением ЯПОН.
VD>>Не удивительно, что с тобой не соглашаются многие (если не большая часть) разработчиков высокой квалификации.
V>Нууу... с позиции активного пользователя языка с развитой макросистемой, ты конечно можешь себе позволить поострить.
Вообще-то с вами не согласны AVK и IB. Они, мягко говоря, Немерл не используют.
V>Но в ситуации, когда никто разрешение на использование Nemerle не даст, даже для разработки внутреннего инструментария, приходится пользовать DSL.
Некорректное противопоставление. Немерле не заменяет DSL-и. Он, наоборот, упрощает их разработку и поощряет их использование.
Что до ваших менеджеров, то или они придерживаются консервативных позиций, или они дятлы. Первое приемлемо когда контора огромная и бюджеты выше крыши. В остальных случаях консерваторы так же являются разновидностью дятлов. Ведь мелкие конторы и проекты могут выживать только на криативных идеях и использовании передовых технологий.
V> Спросишь, кого интересует, на чем пишутся внутренние тулзы?
Мне по фигу. Лично я пишу их (вот уже 2 года) на Немерле. Следующая версия шаблона для верстки статей для РСДН-а та же на Немерле пишется. И я не одинок. Так что процесс потихонечку пошел.
V>Интересует заказчика, если он заказывает разработку, с условием передачи всех относящихся к ней исходников (очень популярный сценарий в заказной разработке). Он примет C/C++/Java/C#/JavaScript/XML и остальные распространенные вещи, а про существование N он даже не в курсе.
Ну, не все же так действуют? Кое кто и ПО продает, а не его исходники.
Если нужно решать более сложные задачи малыми силами, то очень даже стоит задуматься о выборе более мощных средств разработки. Не находишь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Мы уже победили, просто это еще не так заметно...
Или может, стоит посадить специалистов в предметной области и дать им соответствующий инструментарий?
