Топ 10 на GitHub:
Наш рейтинг языков программирования (считали количество сабмитов).
Язык / Количество сабмитов
- C++ 16800
- Java 5288
- C# 5109
- PHP 5053
- Python 3704
- JavaScript 2524
- Ruby 654
- Bash 140
- Swift 137
- Go 120
Итого, невооруженным взглядом видно, что статистика довольно сильно различается(например, swift и go у нас поддержали, хоть и разрыв до лидеров довольно высок).
Если у вас есть мнения по поводу различий рейтингах, то об этом в комментарии плиз.
upd 1:
Недавно публиковали статистику о популярности языков на хакатонах, мы по этой теме напишем чуть позже, в том числе и про онлайн участников
upd 2:
Считаю важным отметить, что WillDev это в первую очередь не HR-сервис и мы по-прежнему своими главными задачами видим создание и развитие самого крутого рейтинга (если интересно, можем выложить больше статистика в соответствии с нашей формулой) и апгрейдом вакансий.
Комментарии (21)
Taras_Serevann
27.08.2015 09:28+6> об этом в комментарии плиз.
> плиз.
Если и дальше хотите вести блог на хабре, то забудьте о таком стиле.
andyudol
27.08.2015 10:51+4Ну и что с чем предлагается сравнивать? У вас — количество решений отправленных на тестирование, а у GitHub? У GitHub — динамика за 7 лет, а у вас?
Правильно было бы сделать так. Выяснить методику GitHub. Сделать выборку на том же GitHubе по только российским разработчикам. Обработать данные по методике GitHub. Сравнить. Сделать выводы.
Плохая статья.
AKarlov
27.08.2015 11:14хм, а зачем выделять разработчиков по стране? оба сервиса вроде бы не привязываются к какой-либо стране
djdeniro
28.08.2015 21:07+1Здесь возможно сделать только часть из того, что вы предложили. Однако прошу заметить то, что «сабмиты» сравнимы с GitHub, ведь «сабмит»=«программа».
В следующий раз будем делать более понятные статьи.
Спасибо
kloppspb
> Количество сабмитов
Чего-чего количество? Оно должно о чём кому-то говорить?
djdeniro
Иными словами это количество решений отправленных на тестирование.
Taras_Serevann
ну так бы и писали
kloppspb
У вас, кстати, нет ни C, ни Perl. Ткнулся в пару задач, понял, что чисто сишный код вы всё равно компилируете как C++ с соответствующими результатами… Так что с объективностью и охватом как-то не очень.
djdeniro
Компилируется как C. Perl в следующем обновлении.
kloppspb
Переключателя «C» ведь нет (или я не нашёл?). А с переключателем C++ компилируется именно как C++, исходник же в .cc забрасывается. Получается, что два разных языка считаются как один :)
djdeniro
Выключили на время тестов :) Включим на днях
kloppspb
Статистику под потребности подгоняете, ну-ну.
djdeniro
Статистика без подгонов, недавно редизайн был, оттуда косяки, но мы исправляем все :)
kloppspb
BTW, вы б объяснили, что здесь не так :-)
const unsigned long long a = (2^75);
const unsigned long long b = ((8^4)-3);
printf( "%llu\n", a % b );
:-)
djdeniro
Тут не одна ошибка
1) Число очень большое, даже больше чем unsigned long long
2) я не уверен на счет вывода, хотя выглядит правдоподобно
kloppspb
Оно по идее должно препроцессором обрабатываться без переполнения, особенно если сразу слить степень и делитель в одном выражении (и не через const). Вот тут, скорее, я сам скосячил: хотел «чисто» проверить, на разных gcc и виндах, но забил :-)
djdeniro
По идее да, но если в структуру лезть, то все равно сначала выделяется память под unsignet long long, туда пихается число, памяти под число не хватает и возникает ошибка :) Здесь либо на «бумажке посчитать» либо пилить длинку в вашем случае
kloppspb
А если попадётся кто-то умный и захочет возвести в степень сдвигом? Gcc и студия ругнутся, конечно (что-то вроде «warning: left shift count >= width of type»), но результат будет совсем не такой как при переполнении. То есть честный ноль :)
djdeniro
На этом мы многих ловим :)