Востребованность языков программирования

tarasv> А не боитесь что в один далеко не прекрасный момент такой метод поставит базу на бок по происзводительности

А мы не используем все эти его ORM-атавизмы. От LINQ to SQL нужно брать лишь самое главное: типизированный проверяемый в compile time язык запросов с трансляцией в SQL.

tarasv> Сергей не становись на позицию Реконструктора - ты шарп не очень знаешь, а Никита знает и его и жабу.

Я не работаю с шарпом, я признаю, что шарп как язык мощнее (что, на самом деле, все-ткаи не значит "лучше", хотя скорее всего таки лучше, практика покажет). Началось все с того, что на мое замечание, что целесообразность генериков для чего-либо кроме контейнеров мне кажется не бесспорной, преуважаемейший никита начал хамить и гнать херню. Бог с ним, агрессивных дураков полно и знание терминов ничего тут не изменит.

На самом деле, лично мне как раз кажется несомненной духовная связь никиты и реконструктора - вера в то, что языковые конструкции/платформа являются определяющими для проектирования. Было бы прикольно никиту поиметь в участниках давешнего конкурса и посмотреть, насколько его выпендреж воплотился бы в практику.

tarasv>Если сначала он выглядел как Java от Микрософт то сейчас это уже реально синтетический и расширяемый язык, с нормальной поддержкой функционального и декларативного программирования.

Еще раз говорю - я согласен. При этом все-таки нельзя ставить знак равенства между богатством языковых средств и качеством языка. Это только практикой и статистикой определяется. Но в целом, скорее всего неудобства Java в деле передачи кода как параметра, скорее ведут к увеличению ошибок и ухудшению качества, ибо они сильно загромождают код и делают его нечитаемым.

*) Что, конечно, не означает отсутствия пользы и удобства от автоматических средств.

Nikita> А мы не используем все эти его ORM-атавизмы. От LINQ to SQL нужно брать лишь самое главное: типизированный проверяемый в compile time язык запросов с трансляцией в SQL.

Вот именно в способности генерировать приличный SQL сложнее select * from Foo where id=123 я и сомневаюсь, уже проходили много раз - на больших объемах данных сложные запросы приходится как минимум твикать если не переписывать вручную.

Сергей-4030> Я не работаю с шарпом, я признаю, что шарп как язык мощнее (что, на самом деле, все-ткаи не значит "лучше", хотя скорее всего таки лучше, практика покажет). Началось все с того, что на мое замечание, что целесообразность генериков для чего-либо кроме контейнеров мне кажется не бесспорной, преуважаемейший никита начал хамить и гнать херню.

Реализация generic в С# не предел совершенства, Степанов бы ее наверно обругал, но она явно лучше чем в Java хотябы поддержкой массивов и примитивных типов. Параметрический полиморфизм, на который как я понял так упирает Никита, позволяет писать компактный код но от читателя требуется недетская подготовка чтобы чтото понять что там написанно. Мечта функциональщика вобщем - его фиг уволят, потому что другой, даже опытный, функциональщик будет разбираться долго. Шютка (с)
Вобще эта разница в подходах к проектированию языка заметна сразу - в Java все explicitly, а implicitly очень редко, а в C# и вобще у Микрософт скорее наоборот. Иногда это доводит до белого каления, за отправку сообщения с помощью email.send = true (на самом деле пофиг можно и email.send = false) я бы убивал.

Сергей-4030> Было бы прикольно никиту поиметь в участниках давешнего конкурса и посмотреть, насколько его выпендреж воплотился бы в практику.

ИМХО в писании простых конечных автоматов особой разницы между C# и Java нет, а вот ворочать в памяти извращенные структуры данных я бы предпочел на C#.

Сергей-4030> Еще раз говорю - я согласен. При этом все-таки нельзя ставить знак равенства между богатством языковых средств и качеством языка. Это только практикой и статистикой определяется.

Функциональщиков банально меньше по причине того что этому надо учить специально и желательно до остальных парадигм, в отличии от процедурного программирования которое доступно любому грамотному инженеру или ООП к которому от процедурного переходят легко по мере набивания шишек.

Сергей-4030> Но в целом, скорее всего неудобства Java в деле передачи кода как параметра, скорее ведут к увеличению ошибок и ухудшению качества, ибо они сильно загромождают код и делают его нечитаемым.

Плюс синтетичсекого языка в том что никто не насилует использовать те возможности которыми ты не хочешь или не умеешь пользоваться. А в чистом ОО языке функциональный код выглядит гораздо страшнее чем "закорючки" чистых функциональщиков - смысл скрыт за танцами с бубном вокруг ограничений языка.

tarasv> Вот именно в способности генерировать приличный SQL сложнее select * from Foo where id=123 я и сомневаюсь,

Что значит "приличный" и что значит "сложнее" ? У языка LINQ to SQL, разумеется, есть ограничения. В частности большое количество конструкций T-SQL - типа fulltext search'а или там CTE - напрямую не поддерживаются. И если они требуются - да, приходится немного прыгать. И что из этого ?

tarasv> уже проходили много раз - на больших объемах данных сложные запросы приходится как минимум твикать если не переписывать вручную.

Если профайлер покажет, что проблема именно в этом - тогда мы её и решим. Напишем stored-процедуру, UDF, сделаем пачку View, перемапим по-другому, в конце-концов реализуем это место по-дедовски - делов-то...

tarasv> Параметрический полиморфизм, на который как я понял так упирает Никита, позволяет писать компактный код но от читателя требуется недетская подготовка чтобы чтото понять что там написанно.

Да вот как раз в том и дело, что именно C# всё резко упростил. Жуть синтаксиса дежурных функциональных языков была заменена практически стандартным C like. Теперь даже индуса можно заставить осилить.

tarasv> Иногда это доводит до белого каления, за отправку сообщения с помощью email.send = true (на самом деле пофиг можно и email.send = false) я бы убивал.

А вот к этому язык отношения не имеет. То что даже Microsoft регулярно не следует своим же FDG - ну так индусы везде.

tarasv> ИМХО в писании простых конечных автоматов особой разницы между C# и Java нет,

Да вот как раз наоборот. То что я в C# на yield return сделаю в пять строчек, на Java будет занимать пять страниц.

>но от читателя требуется недетская подготовка чтобы чтото понять что там написанно

Я тот читатель, оно нечитаемо и недебагируемо.У нас аффтары академически повернуты на использование сложных С++ных конструкций как самоцели, их испортил университет, и вдобавок не пишут комментариев. Если что-то не работает как надо - песец.Авторы языка начиная даже с С повводили нечитаемых конструкций и поощряли студентов их использовать, опять тяжелое наследие университетов.Язык программирования должен быть хотя бы минимально близок к естественному.

tarasv> уже проходили много раз - на больших объемах данных сложные запросы приходится как минимум твикать если не переписывать вручную.

Ну, я на своём фреймворке уже года три, как прямые запросы не использую Хватает ORM'а. Хотя заточен он в первую очередь под MySQL, остальные бэкенды совсем простые.

tarasv> Вот именно в способности генерировать приличный SQL сложнее select * from Foo where id=123 я и сомневаюсь, уже проходили много раз - на больших объемах данных сложные запросы приходится как минимум твикать если не переписывать вручную.

не сомневайся. запрос какого-нибудь отчёта запросто автоматом генерит sql запрос три четыре экрана. или там на первый взгляд простые запросы на подмножестве sql, которые разворачиваются в гигантские конечные sql. И твикают их только для обхода багов в базе данных, а так твикать бесполезно - база должна быть правильно спроектированной, ухоженной, попиленной на ts и т.д..
Как раз таки поддерживать ручные запросы сложнее select * from Foo where id=123 даже в среднем проекте невозможно.

vtvitus> не сомневайся. или там на первый взгляд простые запросы на подмножестве sql, которые разворачиваются в гигантские конечные sql. И твикают их только для обхода багов в базе данных, а так твикать бесполезно - база должна быть правильно спроектированной, ухоженной, попиленной на ts и т.д..

Я совершенно согласен с тем что ORM или генератор репортов, в отличии от человека, не запутается в нескольких десятках алиасов. Но в том что ORM это та технология которая без костылей способна работать с любой базой я очень сомневаюсь, примеры цикла разработки приложения - pure Hibernate on objects only - это быстро и круто, "оба на, а тут без HQL не получается", пошла нагрузка, тормозит все страшнее, "dba сказал что с такими запросами только в морг а тому кто проектировал схему он яйца оторвет" я наблюдал не один раз. И в результате из всей функцуиональности ORM используется только то что есть в каком нибудь myBatis и это при том что танцы с бубном вокруг специфических подходов которые требует применение ORM продолжаются.

tarasv> И в результате из всей функцуиональности ORM используется только то что есть в каком нибудь myBatis и это при том что танцы с бубном вокруг специфических подходов которые требует применение ORM продолжаются.

Вы опять про ORM'ы, тогда как на самом деле речь идёт об интегрированном в систему типов материнского языка SQL'е.

Не нужно городить бессмысленные леса ООП-объектов из данных имеющих реляционную природу. LINQ-to-SQL даёт возможность нормально - строго типизированно и безопасно - обращаться с данными на их родном языке реляционной алгебры.

Nikita> Не нужно городить бессмысленные леса ООП-объектов из данных имеющих реляционную природу. LINQ-to-SQL даёт возможность нормально - строго типизированно и безопасно - обращаться с данными на их родном языке реляционной алгебры.

Всё-таки организация данных в реляционной модели не всегда соответсвтует задаче. Поэтому где-то такая трансляция будет всё равно. LINQ-to-SQL даёт средство для такой трансляции, но не избавляет от неё.

Mishka> Всё-таки организация данных в реляционной модели не всегда соответсвтует задаче.

Это Вы, Капитан ???

Реальные данные практически всегда существенно нормализованы. Хоть реляционные таблицы, хоть графы ООП.

Nikita> Вы опять про ORM'ы, тогда как на самом деле речь идёт об интегрированном в систему типов материнского языка SQL'е.

Это вы про LINQ-to-SQL а vtvitus по меньшей мере не только про него, а скорее вобще не про него.

Nikita> INQ-to-SQL даёт возможность нормально - строго типизированно и безопасно - обращаться с данными на их родном языке реляционной алгебры.

LINQ-to-SQL это syntax sugar в виде embeded SQL с функциональностью на уровне того-же myBatis. Заметная часть прелестей LINQ там просто недоступна.

Nikita> Реальные данные практически всегда существенно нормализованы. Хоть реляционные таблицы, хоть графы ООП.

Нормальные графы ООП просто в реляционую модель не ложаться в общем случае. Нормализация тут не к делу. Это проблемы только реляционной модели. Хотя индусы, конечно, могут напихать кучу дублирования.

tarasv>"оба на, а тут без HQL не получается", пошла нагрузка, тормозит все страшнее, "dba сказал что с такими запросами только в морг а тому кто проектировал схему он яйца оторвет"

У каждого инструмента есть + и -. Нагрузочное тестирование никто не отменял. Надо смотреть чего и как, возможно использовать немного по другому и тогда будет быстрее. Однако мой опыт говорит, что обычно все тормоза
из-за отсутствия какого-нить нужного индекса 80%;
за базой данных не следят - неправильно распределена память, отсутствие регулярного вакуум или реорганизации и т.п. 15%;
незнание некоторых особенностей базы данных (использование parallel query с непониманием чего это стоит по памяти, хитрые типы индексов опять же без понимания и т.п.) 5%.

Сейчас зачастую "спецы" (пальцы веером, ведущие программисты, зп от 100 т.р.) не понимают что такое индексы и как они работают, а валят все на базу данных, неправильный HQL, ORM и т.п.. Так что я бы поостерёгся бы без анализа валить всё на ORM.