А не бывает ли таких ситуаций когда есть возможность выбрать инструмент или поговорить с заказчиком и убедить использовать другой?
А это вообще тонкий вопрос. Тут как повезёт. Некоторые загипнотизированы фразами «новые технологии», «новые возможности». А некоторые думают «а где мы найдем специалистов на этот зоопарк, давайте по-старинке работать?»
Примерно понятно, что Вы имеете в виду. У меня круг задач другой был до недавнего времени.
На счет переполнения чисел для меня была самая болезненная проблема в одном проекте, в котором было много математики. Проект работает, работает, а потом фиг знает где начинает что-то глючить. И разобраться трудно. Приходилось обкладывать проверками вручную. На паскале, например, есть опция компилятора, которая заставляет при переполнении вызывать исключение и отладчик.
В java у меня один раз получилось для частного случая. В базе oracle можно писать процедуры на джаве. Я забыл закрывать какой-то объект для передачи UDP датаграм. Думал, что сборщик мусора должен автоматически закрывать системные хэндлы, а он зараза не закрывал. И после некоторой работы все UDP порты были заняты, что приводило к коллапсу системы.
Надо знать особенности сборщика мусора. Некоторые сборщики не обрабатывают циклические ссылки изза того, что используется счетчик ссылок. К java не относится. На javascript не проверял еще.
Ну вы уж все разберите, а то у меня сомения, — использовать джаву или нет в своих проектах. Сначала купился на рекламу, а копнул глубже и взялся за голову.
За что некоторые не любят java? При большом количестве понтов есть куча неадекватностей. Например:
1) Компилятор не разбирается в константных выражениях. Этот кусок кода компилируется, хотя содержит ошибку, которую можно выявить уже на этапе компиляции.
int i=(false?0:null);
2) Возможно неожиданное зависание в рекурсивной процедуре. Ни какой ошибки не выдается, просто висит.
public static void work(){
try{
work();
}finally{
work();
}
}
3) Все говорят о high perfomance в java. IMHO high perfomance связан с утилизацией оборудования на полную катушку, а java далека от этого. Например, мало кто из джавистов знает, чем отличается физическая память от виртуальной, и что такое блокировка блоков в физической памяти. Ушел процесс в swap и будешь терять миллисекунды при просыпании. В примерах на параллелизм нет анализа, сколько процессоров в системе.
4) Все спрашивающие озабочены деталями, как работает сборщик мусора. IMHO в хорошей системе это не должно быть проблемой.
5) При переполнении числа не выдается ошибка, а просто идет по кругу. То есть можно не заметить переполнения и попортить данные.
int i = Integer.MAX_VALUE+1;
Я нашел пунктов 10, которые меня смущают при всей рекламе крутости java.
Еще одного вопроса нет, который мне несколько раз задавали — «нравится ли вам java?»
Для мне это что-то типа «нравится ли уборщице швабра?» или «нравится ли кузнецу молот?». Мне на самом деле мне нравится решать задачи, а каким образом, — это уже второй вопрос. Обычно приходится решать теми инструментами, которые заказчик предпочитает. Если он захочет забивать гвозди мороженной колбасой, — забью без проблем. :) Эстетов будет воротить, но гвоздь будет забит.
Я тоже подход с case-ом когда то пытался проанализировать. Это похоже на промежуточный вариант между тем, что пишут в ТЗ и мат. логикой, которая основана математических конструкциях.
Моя идея — пиши код почти как написано в ТЗ, а умная оболочка разруливает нестыковки. Если использовать свой язык, как Вы предложили, то это будет ближе к моим идеям. Так на программисте меньше ответственности за ошибки.
Поддерживаю данный подход!
Только, если атрибута 3, то это уже трехмерная матрица. Если их будет штук 40, то полное сочетание в case операторе будет монстром. При добавлении нового атрибута надо будет еще во все места case оператора дописывать еще один уровень вложенности.
Плюс Вы не поняли еще одну фишку моего подхода — дополнительные действия с минисценариями. Их можно анализировать без внесения изменения в базу данных. Например, можно делать легкое регрес-тестирование или прогонять по всей базе не боясь чего-то изменить.
Как это сделать? Очень просто: задавайте себе вопрос «почему?», пока не дойдете до эмоции, лежащей в основе желания. Обычно для этого хватает пяти «почему».
Если задавать вопросы реальному человеку, то обычно конечной точкой являются так называемые сущностные состояния.
А это вообще тонкий вопрос. Тут как повезёт. Некоторые загипнотизированы фразами «новые технологии», «новые возможности». А некоторые думают «а где мы найдем специалистов на этот зоопарк, давайте по-старинке работать?»
На счет переполнения чисел для меня была самая болезненная проблема в одном проекте, в котором было много математики. Проект работает, работает, а потом фиг знает где начинает что-то глючить. И разобраться трудно. Приходилось обкладывать проверками вручную. На паскале, например, есть опция компилятора, которая заставляет при переполнении вызывать исключение и отладчик.
1) Компилятор не разбирается в константных выражениях. Этот кусок кода компилируется, хотя содержит ошибку, которую можно выявить уже на этапе компиляции.
2) Возможно неожиданное зависание в рекурсивной процедуре. Ни какой ошибки не выдается, просто висит.
3) Все говорят о high perfomance в java. IMHO high perfomance связан с утилизацией оборудования на полную катушку, а java далека от этого. Например, мало кто из джавистов знает, чем отличается физическая память от виртуальной, и что такое блокировка блоков в физической памяти. Ушел процесс в swap и будешь терять миллисекунды при просыпании. В примерах на параллелизм нет анализа, сколько процессоров в системе.
4) Все спрашивающие озабочены деталями, как работает сборщик мусора. IMHO в хорошей системе это не должно быть проблемой.
5) При переполнении числа не выдается ошибка, а просто идет по кругу. То есть можно не заметить переполнения и попортить данные.
Я нашел пунктов 10, которые меня смущают при всей рекламе крутости java.
Для мне это что-то типа «нравится ли уборщице швабра?» или «нравится ли кузнецу молот?». Мне на самом деле мне нравится решать задачи, а каким образом, — это уже второй вопрос. Обычно приходится решать теми инструментами, которые заказчик предпочитает. Если он захочет забивать гвозди мороженной колбасой, — забью без проблем. :) Эстетов будет воротить, но гвоздь будет забит.
По моему тут разбор есть: «Ландау Л.Д., Лифшиц Е.М. Теоретическая физика. Том V – М. 1976 – 584 с. „
Маслоу, Абрахам Харольд
Надо будет попробовать реализовать пример из ролика на своем движке
Моя идея — пиши код почти как написано в ТЗ, а умная оболочка разруливает нестыковки. Если использовать свой язык, как Вы предложили, то это будет ближе к моим идеям. Так на программисте меньше ответственности за ошибки.
Только, если атрибута 3, то это уже трехмерная матрица. Если их будет штук 40, то полное сочетание в case операторе будет монстром. При добавлении нового атрибута надо будет еще во все места case оператора дописывать еще один уровень вложенности.
Плюс Вы не поняли еще одну фишку моего подхода — дополнительные действия с минисценариями. Их можно анализировать без внесения изменения в базу данных. Например, можно делать легкое регрес-тестирование или прогонять по всей базе не боясь чего-то изменить.
Так и есть.
Система мутирует много лет и меняются законы для бизнеса, поэтому на ТЗ, которому больше пары лет — уже никто не смотрит.
Если задавать вопросы реальному человеку, то обычно конечной точкой являются так называемые сущностные состояния.