Виталий Пухов

На авианосце, наверняка, огромное количество блоков управления, датчиков, микроконтроллеров и микропроцессоров, а так же более крупных управляющих узлов. И для каждого из них нужна своя программа. А может быть, и специально настроенная операционная система. Все ли датчики и блоки управления дублируются - вероятно, зависит от их важности. Иногда дешевле и надёжнее продублировать, иногда поставить периодическое тестирование, иногда предусмотреть работу при отказавшем узле. Предусмотрено ли несколько версий программ управления на случай "если в одной версии оказалась ошибка - поставим другую" - не уверен. Разве что на время очередного апгрейда и тестирования в реальных условиях.
Но это всё догадки.

Когда превысит будет ошибка

com.parse.ParseException: This application performed 1803 requests within the past minute, and exceeded its request limit. Please retry in one minute or raise your request limit.

А на какое количество пользователей это рассчитано, зависит собственно от мобильного приложения. Посмотри сколько запросов идет от одного клиента в среднем в секунду, потом подели 30 на это число, вот тебе и количество пользователей

Ultimate-редакция VS показывает количество вызовов на методах, можно вполне безопасно удалять методы с нулём вызовов. Хотя зависит от проекта, конечно.

Оставьте дедушку в покое...

Никакие.

Один лишь ЯП в вакууме с точки зрения применения в конечном продукте абсолютно бесполезен. Ибо, как правило, программный продукт существует не обособленно, а, так или иначе, взаимодействует с другими программами (операционной системой, например). Более того, зачастую разумно не изобретать велосипед, а воспользоваться уже готовым решением, которое было проверено временем. Таким образом, приходится знакомиться с кучей уже существующих технологий.

Вообще, в области server / desktop / mobile очень сложно уйти далеко без, как минимум, следующего:

• Объектно-ориентированное программирование и проектирование — ведь код не должен быть говном
  
• Параллельное программирование — ведь делать нужно много и быстро, а у нас уже 10 лет как многоядерные машины есть
  
• Сети — ведь нельзя жить без интернета
  
• Базы данных — ведь данные надо где-то хранить, и хранить надёжно
  

hardware не комментирую, но там ещё хардкорнее.

Собственно, для программиста не столько важно знать какой-либо конкретный ЯП, а важно владеть технологиями разработки. ЯП, конечно, входит в это множество, но им оно совсем не ограничивается.

Надеюсь, что остаток берётся всё-таки от деления на 390, а не на 389 - иначе смысла в коде вообще не видно.
Итак, у нас есть 77 простых чисел, меньших 390. Четыре из них - 2,3,5,13 - не более, чем мусор, дающий лишние срабатывания алгоритма. В самом деле, если x%390==3, то x делится на 3, а значит, оно составное. Остальные 73 числа годятся.
Получается такая картина. Для простого x величина x%390 - некоторое число, взаимно простое с 390. Причём распределены эти остатки более-менее равномерно (на картинке они выглядят как красные столбики). Всего этих остатков 96.
Если x - простое число, то с вероятностью 73/96 остаток будет простым числом, и алгоритм честно скажет "скорее, простое". С вероятностью 23/96 - те самые 25% - остаток окажется составным, и алгоритм ошибётся.
Если x - составное, то вероятность того, что число объявят "скорее, простым" будет равна 77/390-1/ln(x) (первое слагаемое - вероятность того, что остаток оказался простым, а второе - доля простых чисел в окрестности x).
Можно легко избавиться от ошибки первого вида: для этого надо в массив charr положить не простые числа, а числа, взаимно простые с 390. Тогда если алгоритм скажет "составное", то так и есть.
Можно было вместо 390 взять N=30030=2*3*5*7*11*13. Если массив будет заполнен числами, взаимно простыми с N, то отсеиваться, как составные, будет 4 числа из 5, а ложных отсеиваний простых чисел не будет вообще.