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

V> Никто не мешает делать REP на разных языках, ИМХО, это даже полезно.
Чем?

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

V>Зачем???
Затем, что мне нужно решить задачу, а не проблемы интеграции языков между собой.

V>Ведь платформа именно для того и создавалась, чтобы разработчики не парились по поводу использования разных инструментов в одном проекте.
Создавалась она может быть и для этого, но использовать ее в этом качестве пока не получается и я не вижу как это вообще может получиться на практике, а не в красивых теориях.

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

V>А как же популярность Явы?
Вот-вот, Ява намного удобнее C++, однако как только в C# появились генерики и парочка других вкусностей, все с этой явы моментально свалили, и сейчас практически любой писавший и на яве и на шарпе, кроме самых упертых явистов, согласится с тем, что шарп более удобный язык, что лишний раз подтверждает мой тезис.

V>Именно, только в конце приписать надо "для каждой конкретной задачи".
Угу. Вернемся к тому, что есть у меня конкретная задача и часть задачи удобно решать на ООП, а часть ФП, какой язык тут удобен? Ну вот например, есть у меня отличное дерево объектов в C#, но засада — для правильного и красивого вызова нужного метода у нужного экземпляра отлично подошел бы ПМ.
Твои действия:
— Городить визитор ?
— Писать на F# функцию ресолвинга ?
— Ручное выпиливание по тайпкастам ифам и свичам ?

V>Чем более специализирован язык, тем он проще и тем сложнее ошибиться программисту.
Я не вижу практической пользы от заточки языка исключительно на ООП или ФП. И практика показывает, что ни один чистый ООП или ФП язык не оказался пригодным для решения большинства типичных задачь.
Вернемся к предыдущему примеру — мне очевидно, надеюсь и тебе тоже, что при наличии ПМ в C#, данная задача решалась бы существенно проще, и с меньшей вероятностью совершить ошибку, чем любая из доступных сейчас альтернатив.
Так какая польза от того, что язык является чисто ООП или ФП?

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

ВВ>>Давай так. Есть "параметрический полиморфизм",
IB>То есть генерики все таки нужны? Ты уж определись.

А ты читать научись.

ВВ>> есть реализация генериков в 3.5. Второе на уровне контрактов только мешает.
IB>Чем?

Подумай, может сам поймешь.

ВВ>>Это откуда ты такой вывод вывод сделал?
IB>Из твоего заявления, что ты пользуешься не языками, а платформой.
ВВ>> Берем язык-всемогутер (один штука) и гуру-девелопер (один штука). Гуру-девелопер, размахивая языком-всемогутером, начинает работать и спустя всего-то шесть лет — вуаля! — проект готов причем сделан с охрененным качеством. Клиент плачет от радости.
IB>Ты с темы не съезжай, не нужно переводить стрелки с одного языка на одного девелопера.

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

ВВ>>Реальная проблема — это согнать на такой проект человек десять. Разделить задачи. Сделать так, чтобы эти люди работали параллельно и не мешали друг другу. И каждый будет заниматься своей, отдельной задачей, а от языка всемогутера пользы будет мало.
IB>И как ты собрался разделять задачи, если языки разные? И как у тебя разработчики общаться будут и соседский код смотреть, если там язык другой? Ты прям в какой-то другой реальности живешь.

Так же, как и сейчас. Когда большой проект и так создается с использованием десятков инструментов. И какому-нибудь веб-девелоперу не фиг вообще нос совать в код БД. А ты, видимо, в какой-то другой другой реальности живешь.

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

V>>Именно, только в конце приписать надо "для каждой конкретной задачи".
IB>Угу. Вернемся к тому, что есть у меня конкретная задача и часть задачи удобно решать на ООП, а часть ФП, какой язык тут удобен? Ну вот например, есть у меня отличное дерево объектов в C#, но засада — для правильного и красивого вызова нужного метода у нужного экземпляра отлично подошел бы ПМ.
IB>Твои действия:
IB>- Городить визитор ?
IB>- Писать на F# функцию ресолвинга ?
IB>- Ручное выпиливание по тайпкастам ифам и свичам ?

Что делать? Очень просто. Для начала в "консерватории" надо что-то поправить, а не создавать модель с ОО системой типов, которую удобнее всего обрабатывать через ПМ.

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

V>Заведомо нет, а как случайный результат рефакторинга, в котором переименовали какие-нить базовые интерфейсы и включили галочку [переименовать так же все реализации] — запросто.

Рефактринг в принципе штука опасная и для того чтобы быть уверенным в том, что он прошел корректно все равно нужно иметь много юнит-тестов. Они то и должны выявить подобную и другие проблемы.

Хотя конечно я не спорю. Подобные эвристики нисклько не украшают язык и лучше бы их не было вовсе. Тем более, что сразу два более молодых языка в данном примере ведут себя более адекватно (приводят к более адекватному результату).

V>Для паттерн матчинга недостаточно завести одну новую конструкцию языка, для удобного его использования нужны еще конструкции, типа placeholder '_', а это не так просто в плане совместимости с имеющимся кодом.

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

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

V>Опять же, паттерн-матчинг должен быть в C# имеративным, или функциональным?

А switch в C# императивный или функциональный? Так вот паттерн-матчинг — это тоже всего лишь оператор. Конечно, очень желательно, чтобы он был выражением (мок использоваться внутри выражений), но и statment пошел бы на худой конец.

V>Если императивным (ИМХО в ЭТОМ языке — только императивный), то синтаксис утяжеляется обязательным оператором break, как в switch.

Да синтаксис вообще можно оставить switch-ый просто расширв его. Хотя конечно было бы намного удобнее и проще для понимания просто ввести новый оператор аналогичный match в Nemerle. Тем более, что все аспекты его реализации уже отлично проработаны.

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

VD>Основной проблемой будет то что в C# просто нет типов данных которые можно использовать в паттерн-матчинге. Но и это решаемая проблема.

Что-то мне кажется в этом-то как раз основная проблема. Может быть она и решаемая, но этот матч придется прошивать в систему типов по самые помидоры. Так что тут речь не о новой конструкции, а о внедрении принципиально новой концепции. Неудивительно, что они не торопятся делать такие изменения.

Это на каком языке было?

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

ВВ>А ты читать научись.
<...>
ВВ>Подумай, может сам поймешь.
Блестящая аргументация, коллега, по делу есть что сказать? )

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

ВВ> И какому-нибудь веб-девелоперу не фиг вообще нос совать в код БД. А ты, видимо, в какой-то другой другой реальности живешь.
Я живу в той реальности, в которой веб-разработчик (не путать с верстальщиком), обязан знать что делать с БД, так как сайты без БД, в наше время, вряд ли имеют практическую ценность. И даже в том редком случае, когда этому разработчику нет нужды самому писать запросы, он должен иметь представление и практические навыки в том как это все работает, чтобы адекватно выполнять свою часть работы.

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

ВВ>Что делать? Очень просто. Для начала в "консерватории" надо что-то поправить, а не создавать модель с ОО системой типов, которую удобнее всего обрабатывать через ПМ.
Хорошо, давай посмотрим, что у тебя с консерваторией.
Я правильно понимаю, что твой поинт состоит в том, что модель для работы с которой лучше всего подошел бы ПМ — не является true ООП конструкцией и ее надо переделывать по другому? =)
Давай конкретизируем — какую модель ты предложишь, например, для AST, и как будешь с ней работать?

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

ВВ>>А ты читать научись.
IB><...>
ВВ>>Подумай, может сам поймешь.
IB>Блестящая аргументация, коллега, по делу есть что сказать? )

Я очевидные вещи не разжевываю. Как и не повторяю то, что было написано раньше.

ВВ>>Вот только когда девелопер не один высказывания в стиле "мне удобно" со стороны конкретного кодера уже перестают котироваться.
IB>Ну вот и я про то же — в нормальной команде, твои высказывания о том что тебе удобно писать разные части проекта на разных языках вряд ли будут котироваться.

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

ВВ>> И какому-нибудь веб-девелоперу не фиг вообще нос совать в код БД. А ты, видимо, в какой-то другой другой реальности живешь.
IB>Я живу в той реальности, в которой веб-разработчик (не путать с верстальщиком), обязан знать что делать с БД, так как сайты без БД, в наше время, вряд ли имеют практическую ценность. И даже в том редком случае, когда этому разработчику нет нужды самому писать запросы, он должен иметь представление и практические навыки в том как это все работает, чтобы адекватно выполнять свою часть работы.

Выделенное говорит об отсутствии мало-мальской специализации и полноценного разделения труда на твоих проектах. На практике это означает, что "универсальные специалисты" не является по-настоящему хорошими специалистами ни в одной из областей, где они работают. Итоговое качество получается соответствующим. И гордиться тут совершенно нечем.
Веб-разработчик должен знать свое ТЗ и тот слой, с которым он напрямую работает. И у нормальных людей — это не СУБД.

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

IB>Давай конкретизируем — какую модель ты предложишь, например, для AST, и как будешь с ней работать?

AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо.
Если AST в рамках конкретной задачи — это цель, и проектировать ее надо, исходя из этой конкретной задачи, а не рассуждать о сферических конях в вакууме.

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

ВВ>Я очевидные вещи не разжевываю. Как и не повторяю то, что было написано раньше.
Так и запишем — на прямо поставленный вопрос не знает что ответить и по этому начинает хамить. )

ВВ>Мне вообще удобно не писать.
Это я заметил )

ВВ> А разные части проекта *по факту* пишутся на разных языках разными людьми.
У тебя есть идеи, как они договариваются о том, что должно получиться в итоге? )

ВВ>Выделенное говорит об отсутствии мало-мальской специализации и полноценного разделения труда на твоих проектах. На практике это означает, что "универсальные специалисты" не является по-настоящему хорошими специалистами ни в одной из областей, где они работают. Итоговое качество получается соответствующим. И гордиться тут совершенно нечем.
ВВ>Веб-разработчик должен знать свое ТЗ и тот слой, с которым он напрямую работает. И у нормальных людей — это не СУБД.

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

Так я правильно понял твою мысль или нет? )

ВВ>AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо.
Чем слабо? Тем что там нет ПМ? =) Понимаешь, сама по себе трансформация — тоже не конечная цель, и в какой-то момент задача начнет идеально вписываться в ОО и совсем коряво в ФП. И что делать?

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

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

ВВ>>Я очевидные вещи не разжевываю. Как и не повторяю то, что было написано раньше.
IB>Так и запишем — на прямо поставленный вопрос не знает что ответить и по этому начинает хамить. )

Записывай что хочешь. Мне тему "генерики и ООП дизайн" конкретно с тобой обсуждать неинтересно.

ВВ>> А разные части проекта *по факту* пишутся на разных языках разными людьми.
IB>У тебя есть идеи, как они договариваются о том, что должно получиться в итоге? )

А у тебя есть вообще представление о том, как люди в проекте работают? Или ты проект на 2 тыс. человекочасов шесть лет делать собираешься? Или все десять человек у тебя будут и в базе ковыряться, в вебе, и в бизнесе? Есть идеи о том, как такой проект не превратить в помойку?
Судя по тому, что ты пишешь и по истерической реакции (см. ниже) — нет.

ВВ>>Выделенное говорит об отсутствии мало-мальской специализации и полноценного разделения труда на твоих проектах. На практике это означает, что "универсальные специалисты" не является по-настоящему хорошими специалистами ни в одной из областей, где они работают. Итоговое качество получается соответствующим. И гордиться тут совершенно нечем.
ВВ>>Веб-разработчик должен знать свое ТЗ и тот слой, с которым он напрямую работает. И у нормальных людей — это не СУБД.
IB>

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

ВВ>>AST как правило есть не цель, а средство, некий промежуточный этап в трансляции. И при таком подходе, когда нашей итоговой целью является *трансформация* модели, ОО система типов для нее подходит слабо.
IB>Чем слабо? Тем что там нет ПМ? =)

Вообще-то как раз наоборот.

IB>Понимаешь, сама по себе трансформация — тоже не конечная цель, и в какой-то момент задача начнет идеально вписываться в ОО и совсем коряво в ФП. И что делать?

Нет, не понимаю. Для компилятора трансляция из одного представление в другое — конечная цель. То, как ты лично собираешься использовать АСТ, ты не сказал, а догадываться мне не хочется.

ВВ>>Если AST в рамках конкретной задачи — это цель, и проектировать ее надо, исходя из этой конкретной задачи, а не рассуждать о сферических конях в вакууме.
IB>Вот ты и не рассуждай, а спроектируй.

Универсальное АСТ для неизвестной задачи?

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

ВВ>Что-то мне кажется в этом-то как раз основная проблема. Может быть она и решаемая, но этот матч придется прошивать в систему типов по самые помидоры. Так что тут речь не о новой конструкции, а о внедрении принципиально новой концепции. Неудивительно, что они не торопятся делать такие изменения.

Я данную проблему знаю не по наслышке, так что четко понимаю о чем говорю.

У тебя кроме "кажется" какие-то предпосылки есть? Вопрос риторический... можешь не отвечать.

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

В>Это на каком языке было?

F#:

open System
.
.
.

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

ВВ>Записывай что хочешь. Мне тему "генерики и ООП дизайн" конкретно с тобой обсуждать неинтересно.
Слив засчитан.

ВВ>А у тебя есть вообще представление о том, как люди в проекте работают?
И по делу сказать тебе таки нечего. Василий, не стоит тебе со мной проектами меряться, не позорься.

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

Неудобные вопросы ты по прежнему игнорируешь? )

ВВ>Вообще-то как раз наоборот.
Что наоборот?

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

ВВ>Универсальное АСТ для неизвестной задачи?
Ну, например, для задачи рефакторинга и подсветки в редакторе.

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

ВВ>Ты и сейчас наверняка пишешь на нескольких языках в рамках одного проекта. Сюда относятся разные языки разметки, DSL-и и прочее.

Не стоит строить логику на подмене понятий. Использование разных ДСЛ-ей и использование разных языков программирования общего назначения (ЯПОН) — это очень разные вещи.

Кроме того, ДСЛ-и удобны, в основном, когда они встроены в какой-то базовый ЯПОН. И так как в ваших ЯПОН (какими бы они ни были) ДСЛ-и встраиваются в основном в виде текстовых строк, то сразу же встает вопрос потери контроля, так как строки интерпретируются только во время исполнения. Линк и различные генераторы кода — это попытка устранить эту проблему и упростить использование ДСЛ-ей из ЯПОН.

Ты же призываешь к усугублению ситуации — консервации развития ЯПОН и использовании кучи маломощных ЯПОН вместо одного более мощного.

Не удивительно, что с тобой не соглашаются многие (если не большая часть) разработчиков высокой квалификации.

ВВ>Что, неужели возникает желание *все* это писать на шарпе?

Почему обязательно на шарпе? Те кто боится брать языки вышедшие не из под пера МС, конечно предпочитают Шарп. Возможно через некоторое время будут предпочитать F#, как более мощный язык. Ну, а остальные вольны выбирать то что хотят. Лично я выбираю Nemerle, как объективно более мощный по сравнению с C# или F# язык. Но это все равно один язык. Потому как два неудобно.

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