Джава по сравнению с шарпом довольно унылый язык, лишенный кучи удобств последнего. Из собственного опыта (писал и на том и на другом) могу выделить следующие недостатки:
— нет свойств;
— нет лямбд и замыканий;
— нет событий;
— странный механизм аннотаций, который не такой эллегантный как атрибуты в шарпе;
— дженерики поддерживаются на уровне языка, но не на уровне виртуальной машины, что иногда приводит к неудобствам;
— linq — плюшка, без которой можно жить, но жизнь эта как-то уж очень уныла;
— нет вывода типов, динамиков, ко/контравариантности;
Навскидку не могу вспомнить ни одного плюса джавы, которого бы не хватало в шарпе. И это понятно — последний дизайнили исходя из недостатков и сильных сторон джавы.
Так вот весь этот набор плюшек как раз и определяет то, что для написания приложения на джаве нужно на пару десятков процентов больше времени, чем на шарпе, поэтому и выходит дороже. Впрочем, компенсируется эта дороговизна часто лицензиями на ОС, СУБД и т.п. Все дело в масштабах и конкретном проекте.
В том что сам владелец сервиса не владеет инфраструктурой фермы и ему не нужно беспокоится, что она простаивает. Плюс, практически бесконечная масштабируемость в плане возможности обрабатывать множество заказов параллельно.
7%, насколько я знаю. Возможно, конечно, это самая крупная доля среди частных акционеров, не спорю, но утверждать, что Pixar принадлежит Джобсу слегка поспешно.
Pixar принадлежит Диснею. Джобс давным-давно ее продал и сейчас ему принадлежит лишь небольшая доля в компании. Это раз. А два — и что с того? Azure — отличная облачная платфома, Apple на этом рынке не конкурирует с MS, почему бы и нет?
Скажите, а когда планируется открыть marketplace для разработчиков из Украины? Я пытался зарегистрироватся на прошлой неделе, но в выпадающем списке стран не было Украины.
Быстрее, удобнее, эргономичнее. Большинство софта ориентировано на использование с тач-скрином, а не со стилусом — это ИМХО самая большая проблема WM6.5. Чувствуется, что WM6.5 уже морально устарела, в сравнении с Froyo.
Это справедливо только тогда, когда написание более эффективного алгоритма требует больше усилий от программиста или же больший обьем кода. Если вы выбираете между двумя алгоритмами с одинаковой сложностью реализации — почему бы не реализовать тот, который, очевидно, будет работать быстрее. Кроме того, существует целый класс вычислительных задач, в которых сразу и без профайлера видно узкие места.
Вы не учитываете:
а) оптимизацию компилятора, который может отсекать некоторые ветви кода, когда видит, что результат нигде не используется;
б) то что у вас результат накапливается в переменной b, которая быстро стремится к нулю. Функция sin(x) обрабатывает ноль как особый случай.
Попробуйте потестировать следующие примеры:
#include <stdio.h>
#include <math.h>
void main(){
int a;
double b = 1;
for(a=0;a<50000000;a++){
if(a&1) {
b = sin(b);
}
else {
b = sin(1-b);
}
}
printf("%lf\n", b);
}
#include <stdio.h>
#include <math.h>
void main(){
int a;
double b = 1;
for(a=0;a<50000000;a++){
if(a&1) {
b = b/0.3;
}
else {
b = 0.3/b;
}
}
printf("%lf\n", b);
}
Синусы считаются с помощью разложения в ряд, так что FPU придется произвести деление много раз, прежде чем получится результат. Сомневаюсь, что в современных FPU используются тригонометрические таблицы. Или все же используются?
П.С. По опыту олимпиад очень хорошо знаю, что решения на векторной алгебре практически всегда быстрее.
А что удивительного? Я сдал первых два экзамена года через полтора после того как начал работать. Сейчас вот собираюсь сдавать MCPD — и как раз три года как я начал работать разработчиком будет в конце октября.
Думаю, в общем случае работать не будет, так как при посте формы передаются строки и по входящей информации непонятно, как точно их парсить — все же C# язык статический, и вам вряд ли нужно, чтобы все свойства обьекта были строками.
С другой стороны, есть еще одна фича, которая позволяет передавать в метод JSON-обьект, и, мне кажется, не так уж и сложно парсить его и присваивать значения свойствам какого-нибуть ExpandoObject.
— нет свойств;
— нет лямбд и замыканий;
— нет событий;
— странный механизм аннотаций, который не такой эллегантный как атрибуты в шарпе;
— дженерики поддерживаются на уровне языка, но не на уровне виртуальной машины, что иногда приводит к неудобствам;
— linq — плюшка, без которой можно жить, но жизнь эта как-то уж очень уныла;
— нет вывода типов, динамиков, ко/контравариантности;
Навскидку не могу вспомнить ни одного плюса джавы, которого бы не хватало в шарпе. И это понятно — последний дизайнили исходя из недостатков и сильных сторон джавы.
Так вот весь этот набор плюшек как раз и определяет то, что для написания приложения на джаве нужно на пару десятков процентов больше времени, чем на шарпе, поэтому и выходит дороже. Впрочем, компенсируется эта дороговизна часто лицензиями на ОС, СУБД и т.п. Все дело в масштабах и конкретном проекте.
Заклинило на этом пункте. ЕМНИП, «framework» как раз и переводится как «каркас».
Извините за оффтоп :)
а) оптимизацию компилятора, который может отсекать некоторые ветви кода, когда видит, что результат нигде не используется;
б) то что у вас результат накапливается в переменной b, которая быстро стремится к нулю. Функция sin(x) обрабатывает ноль как особый случай.
Попробуйте потестировать следующие примеры:
П.С. По опыту олимпиад очень хорошо знаю, что решения на векторной алгебре практически всегда быстрее.
Например:
вполне легко распарсить как вот такой обьект на C#:
С другой стороны, есть еще одна фича, которая позволяет передавать в метод JSON-обьект, и, мне кажется, не так уж и сложно парсить его и присваивать значения свойствам какого-нибуть ExpandoObject.