Бежать из страны можно… только ситуации это не изменит.
Да и от самого себя убежать не получится.
Когда до большинства это дойдет, может, что-то и поменяется.
Как правило это будет определяться конкретной задачей. Если значения используются часто (а проверить это можно только на практике или после тщательного анализа предметной области), то выигрыш будет, нет — значит, нет.
Про float.
Как правило для большинства задач можно задать более-менее объективную границу отсечения (например, 3 знака после запятой), и все float-значения перед обработкой округлять до заданной границы. Это снимет проблему повторных вычислений и (!), что более важно, потенциальные ошибки сравнения (float_1 == float_2).
Также можно добавить, что средствами AspectJ можно, немного подумав, реализовать автоматическое кеширование для методов с определенной сигнатурой.
Предлагаю освятить это в следующей статье.
Если 1 Гб будет стоить рубль, то я, пожулай, возьму с учитываемым траффиком =) потому что используя анлим я буду тратить больше =) Логично ведь?
Кстати, это относится и к мобильникам. У Вас сейчас мобильным анлим, не так ли?
Насчет Word — не согласен ) Открываешь файлик страниц этак на 200, и все подвисает… Конечно, рост производительности это рано или поздно лечит, но не отменяет возможности параллелизации. Если удастся распараллелить хотя бы половину задач — втанет работать в полтора раза быстрее, и это будет очень и очень неплохо ) не так ли?
А по существу — пишем, конечно, мы медленне, чем печатаем (если рассматривать те же липкие листы и их аналог на компе).
Но! На бумаге можно сделать то, чего нельзя сделать (быстро) в текстовой форме — например, вставлять в текст изображения или начертить схему. В этом случае я, как программист, использую маленькие отрывные листики — гораздо удобнее и эффективнее.
Не всегда.
На самом деле данное суждение зависит от множества факторов. Сразу предупреждаю, список неполный, перечислю то, что сразу приходит в голову.
Факторы:
1) Динамичность проекта. Если после написания кода прошел год и логика приложения и/или предметной области к тому времени существенно поменялась (требования заказчика изменились/расширились), то код конечно же будет некорректным, т.к. он не будет отражать существующего порядка. Тем не менее на момент написания он мог быть очень хорошим кодом.
2) Участие в проекте нескольких разработчиков. При этом каждый разработчик отчетливо представляет себе только часть системы. Вероятность внесения ошибок на границе ответственности довольно велика, и в итоге код со временем уже не справляется с поставленными перед ним задачами. Хотя в момент его написания все опять же могло быть хорошо.
X) Длительное отсутствие рефакторинга. Этот пункт излагается в конце, т.к. перед ним излагаются предпосылки, но по значимости он должен стоять в начале. Отсутствие рефакторинга приводит к тому, что со временем влияние вышеперечисленных факторов возрастает, и в конце-концов приводит к ужасному коду.
Перед пунктом X можно понаписать еще кучу причин, я назвал основные. Например, недостаточная квалификация отдельных разработчиков, невнимательность, реализация частных случаев вместо общих и т.д.
P.S. Те же причины приводят не только к говнокоду (что не хорошо, но терпимо), но и к появлению ошибок в программе, что гораздо более печально с точки зрения заказчика.
Напоследок приведу хорошую аналогию. Есть в комнате долго не делать уборку, то даже если там никто ничего не будет трогать, рано или поздно там станет настолько грязно, что противно будет зайти =)
Думаю, дело не в том, что предоставляется иллюзия объектной модели, а в том, что покрытие неполное. В итоге при возникновении проблем приходится детально разбираться, что происходит и почему, и требует для использования серьезной подготовки не только в части ORM framework'а, а также в структуре и принципах работы самих реляционных БД.
А насчет иллюзии объектной модели в памяти — там-таки данная полнота присутствует, и при отсутствии хаков (а именно — отсутствии прямой работы с памятью, отведенной под объект, и магических cast'ов) данных функционал работает именно так, как ожидается.
Насколько я помню, за первое пока еще никто никого к ответственности не призывал.
Да и от самого себя убежать не получится.
Когда до большинства это дойдет, может, что-то и поменяется.
Как правило для большинства задач можно задать более-менее объективную границу отсечения (например, 3 знака после запятой), и все float-значения перед обработкой округлять до заданной границы. Это снимет проблему повторных вычислений и (!), что более важно, потенциальные ошибки сравнения (float_1 == float_2).
Предлагаю освятить это в следующей статье.
public R memorize(Callable fubc, final Map<Callable,R> obj) {… }
public R memorize(Callable fubc, final Map<Callable,R> obj) {… }
Стандартная нотация :-)
Кстати, это относится и к мобильникам. У Вас сейчас мобильным анлим, не так ли?
А по существу — пишем, конечно, мы медленне, чем печатаем (если рассматривать те же липкие листы и их аналог на компе).
Но! На бумаге можно сделать то, чего нельзя сделать (быстро) в текстовой форме — например, вставлять в текст изображения или начертить схему. В этом случае я, как программист, использую маленькие отрывные листики — гораздо удобнее и эффективнее.
На самом деле данное суждение зависит от множества факторов. Сразу предупреждаю, список неполный, перечислю то, что сразу приходит в голову.
Факторы:
1) Динамичность проекта. Если после написания кода прошел год и логика приложения и/или предметной области к тому времени существенно поменялась (требования заказчика изменились/расширились), то код конечно же будет некорректным, т.к. он не будет отражать существующего порядка. Тем не менее на момент написания он мог быть очень хорошим кодом.
2) Участие в проекте нескольких разработчиков. При этом каждый разработчик отчетливо представляет себе только часть системы. Вероятность внесения ошибок на границе ответственности довольно велика, и в итоге код со временем уже не справляется с поставленными перед ним задачами. Хотя в момент его написания все опять же могло быть хорошо.
X) Длительное отсутствие рефакторинга. Этот пункт излагается в конце, т.к. перед ним излагаются предпосылки, но по значимости он должен стоять в начале. Отсутствие рефакторинга приводит к тому, что со временем влияние вышеперечисленных факторов возрастает, и в конце-концов приводит к ужасному коду.
Перед пунктом X можно понаписать еще кучу причин, я назвал основные. Например, недостаточная квалификация отдельных разработчиков, невнимательность, реализация частных случаев вместо общих и т.д.
P.S. Те же причины приводят не только к говнокоду (что не хорошо, но терпимо), но и к появлению ошибок в программе, что гораздо более печально с точки зрения заказчика.
Напоследок приведу хорошую аналогию. Есть в комнате долго не делать уборку, то даже если там никто ничего не будет трогать, рано или поздно там станет настолько грязно, что противно будет зайти =)
www.citforum.ru/SE/project/pattern/
Думаю, дело не в том, что предоставляется иллюзия объектной модели, а в том, что покрытие неполное. В итоге при возникновении проблем приходится детально разбираться, что происходит и почему, и требует для использования серьезной подготовки не только в части ORM framework'а, а также в структуре и принципах работы самих реляционных БД.
А насчет иллюзии объектной модели в памяти — там-таки данная полнота присутствует, и при отсутствии хаков (а именно — отсутствии прямой работы с памятью, отведенной под объект, и магических cast'ов) данных функционал работает именно так, как ожидается.