Здравствуйте, neFormal, Вы писали:
VR>>>но, для изучения всех этих ништяков, нужно приложить усилие, в следствии чего, многие lazy developers предпочтут питон,руби C>>Ну и славно, если так. Значит меньше низкопробных программистов останется на дотнет. Может и индусы перейдут на пайтон... Очень хотелось бы верить.
F>хочется побыть илитой?.
Простите что? F>изучи буст,
Давно (хотя мои знания про boost наверняка устарели).
F>покажи шаблонную магию им.Александреску.. и все будут тебе завидовать..
Нет там никакой магии. Вот AOP, основанное на IL-weaving куда больше похоже на магию.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Итак слезать с шарпа (не в том смысле, что "безвозвратно переходить с него на другие языки", а в том, что "избавляться от шарповой зависимости") надо по следующим причинам:
RO>0. Он привязан к одной ОС. Дальше и обсуждать нечего.
Неправда, см Mono — для *nix, MacOS, iPhone. SL запускается под маком.
Для устройств на базе ARM или Blackfin есть .NET Micro Framework.
А теперь еще появилась платформа .NET для роботов (еще не смотрел, подробнее не скажу).
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Константин Б., Вы писали:
КБ>>>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах? F>>>например, чтобы работать с объектами, а не с голыми данными.. КБ>>А в чем профит-то? Данные они и есть данные, что в виде объекта, что в виде кортежа. Если надо вместе с данными куда-то передать и функции их обработки, то в питоне это не проблема. Даже гибче получается, потому что можно в разных местах разные функции использовать. F>профит в инкапсуляции..
Раскройте этот момент поподробнее. Инкапсуляции чего от чего.
F>еще например, в django можно при объявлении члена класса указать какого типа будет поле, какие у него настройки, указать некоторые настройки для таблицы и т.п.. Потом вызвать один скрипт и всё это будет создано в базе..
Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
Здравствуйте, gandjustas, Вы писали:
G>Бред в основном эксперты пишут. Я постоянно работаю с разными браузерами, так вот именно с помощью файерфокс большенство XSRF-атак можно выполнять, кроме того FF медленнее всех работает с DOM, очень часто падает на экзотических джаваскриптах.
Про DOM это давно не так.
Про javascript — noscript рулит.
G>К IE только две претензии: медленный и не очень соотвествует стандартам (до 8 версии)
А что 8ка наконец соответствует стандартам? 6ка и 7ка это СУЩИЙ ужас для javascript разработчика. Посмотрите код ExtJs — СПЛОШНЫЕ костыли в js и css для IE...
G>Восьмая версия эксплорера вообще в какашки рвет все браузеры по юзабилити,
Не заметил.
Здравствуйте, criosray, Вы писали:
F>>тем более применение плюсов возможно более широкое, чем шарпа.. C>Если речь о рациональном применении, то нет. Конечно не более широкое. Другое — да, более широкое — уж никак нет.
и, конечно же, этому есть подтверждение?.
F>>разница только в том, что плюсы не пихают куда только можно, а шарп пихают.. C>Это шутка такая?
какие уж тут шутки?. десктоп, веб, игры и прочее.. везде туда пихают шарп..
мэйнстрим такой мэйнстрим..
Здравствуйте, criosray, Вы писали:
КБ>>>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах? C>>>Потому данные сами по себе в отрыве от доменной модели ценности не несут. КБ>>Что есть по вашему "доменная модель" и почему для нее обязательно нужны объекты?
C>Google в тооооом направлении --> C>Объяснять элементарное и базовое не в моих принципах.
Я там уже был. Что из этого вы имеет ввиду.
C>>>O/RM это ведь не просто мэппинг. Это еще UnitOfWork, кеширование, cascading и т.д.
КБ>>... и другие костыли, C>Костыли?
Разве нет? В чем же профит от этих штук?
КБ>>которые нужны если мы начинаем городить объекты. А если не создавать объекты, то это все и не нужно. C>Мда...
Здравствуйте, Константин Б., Вы писали:
КБ>Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
Вы похоже совершенно не понимаете о чем речь? Вот у нас доменная модель на более сотни сущностей. Как со всей этой кухней работать без ОРМ и без объектов???
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, vit.rsdn, Вы писали:
v>> у Руби есть менее производительное и более нестабильное решение Ruby on Rails v>> а чем таким обладает питон?
AB>Django?
в дополнение, интересный момент ,почему гугл включила весьма ограниченную поддержку этого проекта в своих Google Appsю Полноценная поддержка вызвала бы лавинообразный рост количество Python-девелоперов, мигрируеющий с РНР/ Ruby
Здравствуйте, Константин Б., Вы писали:
F>>профит в инкапсуляции.. КБ>Раскройте этот момент поподробнее. Инкапсуляции чего от чего.
инкапсуляция данных и средств работы с бд..
на всякий случай:
Инкапсуля́ция — свойство языка программирования, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя. При этом пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только через этот интерфейс.
КБ>Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
нет, мы приходим к вопросу "делать всё руками или автоматизировать?"
ясен пень, можно всё сделать самому.. но зачем, если можно проще?.
F>>>тем более применение плюсов возможно более широкое, чем шарпа.. C>>Если речь о рациональном применении, то нет. Конечно не более широкое. Другое — да, более широкое — уж никак нет.
F>и, конечно же, этому есть подтверждение?.
Сплошь и рядом. Весь корпоративный спектр приложений по-сути.
F>>>разница только в том, что плюсы не пихают куда только можно, а шарп пихают.. C>>Это шутка такая?
F>какие уж тут шутки?. десктоп, веб, игры и прочее.. везде туда пихают шарп..
Шарп в играх? Просвятите. В Веб ему самое место. Ему и джаве. Десктоп пока что-то не заметил, чтоб было много программ на дотнет. Share/Free ware почти все на С++.
F>мэйнстрим такой мэйнстрим..
И?
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
C>Вы похоже совершенно не понимаете о чем речь? Вот у нас доменная модель на более сотни сущностей. Как со всей этой кухней работать без ОРМ и без объектов???
Здравствуйте, Константин Б., Вы писали:
КБ>>>>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах? C>>>>Потому данные сами по себе в отрыве от доменной модели ценности не несут. КБ>>>Что есть по вашему "доменная модель" и почему для нее обязательно нужны объекты?
C>>Google в тооооом направлении --> C>>Объяснять элементарное и базовое не в моих принципах.
КБ>Я там уже был. Что из этого вы имеет ввиду.
http://en.wikipedia.org/wiki/Domain-driven_design
C>>>>O/RM это ведь не просто мэппинг. Это еще UnitOfWork, кеширование, cascading и т.д.
КБ>>>... и другие костыли, C>>Костыли?
КБ>Разве нет? В чем же профит от этих штук?
Ну разберитесь для начала что это за штуки, тогда сами поймете в чем же профит.
КБ>>>которые нужны если мы начинаем городить объекты. А если не создавать объекты, то это все и не нужно. C>>Мда... КБ>Не согласны?
Естественно.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
F>>>>4. Он не позволяет решать весь спектр задач. F>>>>Поэтому зависимость от шарпов больше порождена религиозными убеждениями, чем здравым смыслом. C>>>Вот это Ваше сообщение порождено религиозными убеждениями, а не здравым смыслом.
C>>>Единственное, что не позволяет дотнет — писать драйверы. G>>Неправда, см Singularity. G>>Это утверждение стоит написать как ".NET не позволяет писать драйверы для существующих ОС". C>Я в курсе про сингулярити. Но сингулярити это проект на бумаге, так что не вижу смысла его упоминать...
У кого-то на бумаге, а у меня на виртуалке очень даже запускается.
КБ>>>Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
C>>Вы похоже совершенно не понимаете о чем речь? Вот у нас доменная модель на более сотни сущностей. Как со всей этой кухней работать без ОРМ и без объектов???
КБ>А в чем проблема то?
КБ>
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
F>>>это невозможно в принципе, т.к. оно заточено под одну платформу.. G>>И чем это мешает?
F>тем, что невозможно это применить во многих случаях.. с достаточной эффективностью..
В каких случаях, и что такое достаточная эффективность?
Здравствуйте, gandjustas, Вы писали:
C>>>>Единственное, что не позволяет дотнет — писать драйверы. G>>>Неправда, см Singularity. G>>>Это утверждение стоит написать как ".NET не позволяет писать драйверы для существующих ОС". C>>Я в курсе про сингулярити. Но сингулярити это проект на бумаге, так что не вижу смысла его упоминать... G>У кого-то на бумаге, а у меня на виртуалке очень даже запускается.
Запускается — чудесно... Ну а дальше-то что?
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>>>Главный плюс ОРМ — статическая типизация. Если ее нет, то зачем городить еще что-то поверх SQL? G>>>Нужно как-то преобразовывать результирующий recordset в объекты, а также изменения в объектах записывать в БД. G>>>Сам маппинг полей таблиц в свойства объектов уже давно является тривиальной задачей.
КБ>>А зачем в питоне преобразовывать recordset в объекты? Чем плохи наборы данных в кортежах?
C>Потому данные сами по себе в отрыве от доменной модели ценности не несут.
Хм.. например вам нужно отобразить список заказов (номер и сумма) с именем клиента. Вы же не тянете для этого полный объект (domain object) заказа с объектом клиента и списком всех позичий заказа?
Здравствуйте, criosray, Вы писали:
C>>>Если речь о рациональном применении, то нет. Конечно не более широкое. Другое — да, более широкое — уж никак нет. F>>и, конечно же, этому есть подтверждение?. C>Сплошь и рядом. Весь корпоративный спектр приложений по-сути.
и?. где обещаная широта?.
F>>>>разница только в том, что плюсы не пихают куда только можно, а шарп пихают.. C>>>Это шутка такая?
F>>какие уж тут шутки?. десктоп, веб, игры и прочее.. везде туда пихают шарп.. C>Шарп в играх? Просвятите.
http://unity3d.com/unity/features/scripting
Красивая, интересная технология, но довольно спорная имхо.. Шарп там один из возможных средств разработки..
F>>мэйнстрим такой мэйнстрим.. C>И?
ничего в этом хорошего..
нас всегда учили, что инструмент выбирают под задачу, а не задачу под инструмент и уж тем более не затачивают инструмент для применения всегда и везде..
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Константин Б., Вы писали:
F>>>профит в инкапсуляции.. КБ>>Раскройте этот момент поподробнее. Инкапсуляции чего от чего.
F>инкапсуляция данных и средств работы с бд.. F>на всякий случай: F>
F>Инкапсуля́ция — свойство языка программирования, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя. При этом пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только через этот интерфейс.
Вы предлагаете работать с БД через интерфейс объекта? O_o А как же SRP, LSP и другие прекрасные абревиатуры?
КБ>>Здорово. Т.е. у нас есть объекты, а по ним генерится БД. А если у нас объектов нет, то можем просто написать вызов CREATE TABLE. Т.е. опять же возвращаемся к вопросу о необходимости объектов.
F>нет, мы приходим к вопросу "делать всё руками или автоматизировать?" F>ясен пень, можно всё сделать самому.. но зачем, если можно проще?.
Неправда. Ваш вариант — написать руками объекты и из них сгенерить CREATE TABLE. Мой — сразу написать CREATE TABLE. И там и там приходится писать руками.
Здравствуйте, gandjustas, Вы писали:
F>>>>это невозможно в принципе, т.к. оно заточено под одну платформу.. G>>>И чем это мешает? F>>тем, что невозможно это применить во многих случаях.. с достаточной эффективностью.. G>В каких случаях
в случаях, выходящих за эту единственную платформу
G>и что такое достаточная эффективность?
