Что удивительно, этому определению очень хорошо — прямо-таки идеально соответствует Erlang — язык, который _никогда_ не заявлял, что он имеет отношение к ООП
Вы еще забыли про Смолтолковский true message passing, когда описывали «чистый» ООП. А еще, что интересно, ООП может относиться не к языку, а к технологии. COM тому пример.
А тот «странный» человек, с которым вы спорили, в некотором смысле прав. Только он сильно путает принципы и реализацию, и еще фанатично уверен в том, что ООП бывает только прототипный.
Основа ООП — это message passing, что в современных скриптовых языках реализуется как динамическая типизация и механизм call-by-name, отсюда и его высказывания про то, что «динамизм — основа ООП».
Далее, в случае прототипного ООП исчезают сами классы, отсюда и наследование в классическом понимании тоже исчезает, потому он и говорит, что «наследование для ООП чужеродно».
Думаю, что фанатизма надо меньше, а терпимости к чужой точке зрения больше. Тем более, что, как ни странно, вы оба правы (пока дело не доходит до взаимных оскорбительных выпадов)
Если вы юзаете long-running «business» transactions (LRT), простирающиеся на несколько system «db» transactions, то вам, скорее всего, захочется иметь batch insert сущностей по окончании LRT, и не раньше. В случае, когда id генерится БД, вы это (batch insert) сделать не можете, т.к. создание сущности требует заполнения её id, за коим приходится лезть в БД, что ломает саму идею отсоединенной LRT.
Для MS SQL, в котором нет генераторов a la sequence, как в Oracle, это вообще вырождается в обязательную вставку объекта в БД.
Поэтому в таких случаях есть смысл юзать application-generated id — по алгоритмам HiLow или Guid.Comb. Особенно хорошо это описано в блогах авторов Hibernate/NHibernate
Неправда ваша. Как сконфигурите, так и будет.
И вообще, при использовании ОРМ, autogenerated id вообще не стоит юзать, но уже по другим причинам, не охваченным статьей
Хе-хе, я из ваших комментариев уже понял, что вы большой специалист по раскраске графов. И всё же я рекомендую вам иногда читать что-нибудь кроме Википедии. А лучше — самому заниматься практическим решением таких проблем. Потому что «распределить хорошо» — это расплывчатое теоретическое понятие. А вот распределить «удовлетворительно» — вполне нормально для практики.
А количество регистров в ARM можно посмотреть в той же Википедии. В самых простых RISC-машинах (типа AVR-контроллеров) их меньше 30 бывает редко. В той же Википедии написано, что еще существует стек ;) Как организовывать кадры стека на регистрах и наоборот, вытеснять регистры в стек, думаю, вы тоже должны знать.
Остальное по индукции
>>… оптимального результата нельзя достигнуть…
Не оптимального, а наилучшего. Оптимальный достичь можно, но он не будет абсолютно лучшмм. Поэтому ищется не наилучший, а оптимальный по отношению к оценочной функции.
В случае с ARM-процессорами оценочная функция, например — минимальное число копирований между регистрами, сами регистры ортогональны и равнозначны. Так что какие графы, распределение регистров делается простым табличным способом. Это быстро.
Вот поэтому-то и нет большого смысла сравнивать С++ и С# — ожидая результат «С++ быстрее С# anyway», мало толку искать этот ответ:
— если по результатам побеждает С++, публика кричит «воооот, а мы говорили же!», и на результаты не смотрит в принципе, даже если у С++ опережение в 2-5%.
— если по результатам побеждает С#, начинаются обвинения автора в том, что он не умеет писать на С++/подтасовал данные/С#-программу оптимизировал, а С++ нет/не знает хороших библиотек (нужное подчеркнуть) и уж точно С++программу можно было бы сделать быстрее :) Конечно, можно — в С++ теоретически больше контроль над тем, что ты делаешь. Но в С++ это — можно сделать, потратив дополнительно ресурсы — время или деньги на действительно хорошего С++программиста, а в С# — напедалил и готово.
А мне статья очень понравилась.
С одной стороны, это success story. С другой стороны, довольно нетипичная, могло и не взлететь. А такого большого количества комментариев со смыслом я давно не видел. Спасибо всем!
Дело в том, что в упомянутом примере GCC (в случае с С++, например) делает огромное количество работы: парсинг и репарсинг текста программы, лексический, семантический и синтаксический анализ результатов парсинга, составление ее абстрактного дерева, распределение ресурсов и т.д.
В случае с JIT работы намного меньше — JIT компилирует из промежуточного представления, больше всего похожего на обычный ассемблер. В самом простом случае всё, что ему нужно сделать — распределить регистры и вычислить метки переходов.
Сравните скорость компиляции GCC/C++ и GAS (если вы в Linux), и вы поймете, насколько JITу проще.
Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова… Пользователь может играть лесными эльфами, охраной дворца и злодеем. И если пользователь играет эльфами то эльфы в лесу, домики деревяные набигают солдаты дворца и злодеи. Можно грабить корованы… И эльфу раз лесные то сделать так что там густой лес… А движок можно поставить так что вдали деревья картинкой, когда подходиш они преобразовываются в 3-хмерные деревья[1]. Можно покупать и т.п. возможности как в Daggerfall. И враги 3-хмерные тоже, и труп тоже 3д. Можно прыгать и т.п. Если играть за охрану дворца то надо слушаться командира, и защищать дворец от злого (имя я не придумал) и шпионов, партизанов эльфов, и ходит на набеги на когото из этих (эльфов, злого...). Ну а если за злого… то значит шпионы или партизаны эльфов иногда нападают, пользователь сам себе командир может делать что сам захочет прикажет своим войскам с ним самим напасть на дворец и пойдет в атаку. Всего в игре 4 зоны. Т.е. карта и на ней есть 4 зоны, 1 — зона людей (нейтрал), 2- зона императора (где дворец), 3-зона эльфов, 4 — зона злого… (в горах, там есть старый форт...) Так же чтобы в игре могли не только убить но и отрубить руку и если пользователя не вылечат то он умрет, так же выколоть глаз но пользователь может не умереть а просто пол экрана не видеть, или достать или купить протез, если ногу тоже либо умреш либо будеш ползать либо на коляске котаться, или самое хорошее… поставить протез. Сохранятся можно…
P.S. Я джва года хочу такую игру.
Да я не про деньги, которые платят вам за деятельность переписчика, я в целом про з/п.
Вот смотрите: 30% фантомного населения значит, что реальный бюджет по налогам настолько же меньше.
Вот и думайте, что это значит. Ведь бюджет — это з/п для социальных служб и бюджетных организаций.
Ваших детей будут учить на 30% меньше, зубы вам в стоматологии будут доделывать на 70% и выгонять нах из кресла, хирург будет вам зашивать 70% шва и удалять 70% аппендицита (не дай Б-г)
О как всё повернулось, да?
Да просто ебанулся товарищ. 30% неверных — это 30 человек придуманных на каждые 100 человек.
Ахтунг! Это 30-40 миллионов «мертвых душ»
Вопрос к переписчику — если вам з/п платить с актуальностью 70% от указанной в договоре, вы сильно обидитесь? Не, ну а чо, для тех условий в стране, в которой мы живем, вполне неплохо, ы?
Скажите, а зачем надо было переопределять поведение стандартного оконного меню на нестандартное? Если выбрать пункт в главном меню слева, например «Файл», а затем увести мышку на пункт «Правка», то меню «правка» не открывается, в то время, как во _всех_ приложения под Windows должно открыться?
А тот «странный» человек, с которым вы спорили, в некотором смысле прав. Только он сильно путает принципы и реализацию, и еще фанатично уверен в том, что ООП бывает только прототипный.
Основа ООП — это message passing, что в современных скриптовых языках реализуется как динамическая типизация и механизм call-by-name, отсюда и его высказывания про то, что «динамизм — основа ООП».
Далее, в случае прототипного ООП исчезают сами классы, отсюда и наследование в классическом понимании тоже исчезает, потому он и говорит, что «наследование для ООП чужеродно».
Думаю, что фанатизма надо меньше, а терпимости к чужой точке зрения больше. Тем более, что, как ни странно, вы оба правы (пока дело не доходит до взаимных оскорбительных выпадов)
Если вы знакомы с термином Unit of Work, вы поймёте, о чем я.
Для MS SQL, в котором нет генераторов a la sequence, как в Oracle, это вообще вырождается в обязательную вставку объекта в БД.
Поэтому в таких случаях есть смысл юзать application-generated id — по алгоритмам HiLow или Guid.Comb. Особенно хорошо это описано в блогах авторов Hibernate/NHibernate
И вообще, при использовании ОРМ, autogenerated id вообще не стоит юзать, но уже по другим причинам, не охваченным статьей
А количество регистров в ARM можно посмотреть в той же Википедии. В самых простых RISC-машинах (типа AVR-контроллеров) их меньше 30 бывает редко. В той же Википедии написано, что еще существует стек ;) Как организовывать кадры стека на регистрах и наоборот, вытеснять регистры в стек, думаю, вы тоже должны знать.
Остальное по индукции
Не оптимального, а наилучшего. Оптимальный достичь можно, но он не будет абсолютно лучшмм. Поэтому ищется не наилучший, а оптимальный по отношению к оценочной функции.
В случае с ARM-процессорами оценочная функция, например — минимальное число копирований между регистрами, сами регистры ортогональны и равнозначны. Так что какие графы, распределение регистров делается простым табличным способом. Это быстро.
— если по результатам побеждает С++, публика кричит «воооот, а мы говорили же!», и на результаты не смотрит в принципе, даже если у С++ опережение в 2-5%.
— если по результатам побеждает С#, начинаются обвинения автора в том, что он не умеет писать на С++/подтасовал данные/С#-программу оптимизировал, а С++ нет/не знает хороших библиотек (нужное подчеркнуть) и уж точно С++программу можно было бы сделать быстрее :) Конечно, можно — в С++ теоретически больше контроль над тем, что ты делаешь. Но в С++ это — можно сделать, потратив дополнительно ресурсы — время или деньги на действительно хорошего С++программиста, а в С# — напедалил и готово.
С одной стороны, это success story. С другой стороны, довольно нетипичная, могло и не взлететь. А такого большого количества комментариев со смыслом я давно не видел. Спасибо всем!
В случае с JIT работы намного меньше — JIT компилирует из промежуточного представления, больше всего похожего на обычный ассемблер. В самом простом случае всё, что ему нужно сделать — распределить регистры и вычислить метки переходов.
Сравните скорость компиляции GCC/C++ и GAS (если вы в Linux), и вы поймете, насколько JITу проще.
P.S. Я джва года хочу такую игру.
news.rambler.ru/7968516/
Вот смотрите: 30% фантомного населения значит, что реальный бюджет по налогам настолько же меньше.
Вот и думайте, что это значит. Ведь бюджет — это з/п для социальных служб и бюджетных организаций.
Ваших детей будут учить на 30% меньше, зубы вам в стоматологии будут доделывать на 70% и выгонять нах из кресла, хирург будет вам зашивать 70% шва и удалять 70% аппендицита (не дай Б-г)
О как всё повернулось, да?
Ахтунг! Это 30-40 миллионов «мертвых душ»
Вопрос к переписчику — если вам з/п платить с актуальностью 70% от указанной в договоре, вы сильно обидитесь? Не, ну а чо, для тех условий в стране, в которой мы живем, вполне неплохо, ы?