Да ладно, restframework - это та еще сатана. Явно проект не для новичка - новичку в нем разобрать на нормальном уровне нетривиально, не то чтобы туда пул-реквесты слать. Вы сами-то пробовали?
Серьезно? К какому порядку? По рукам не бьет в случае ошибок, ресурсов у любой современной системы и так много, чтобы новичок наглядно отличия оптимизированного hello world'а от неоптимизированного. К порядку приучит наставник, но никак не язык.
Изучать нужно не с языка со статической типизацией, а с языка с сильной. Ну какая будет польза от статической слабой типизации? И типы нужно самому объявлять, и компилятор подсказывать и бить по рукам не будет.
А Го конечно интересный, но крайне примитивный. И вдобавок приучит к своеобразному ООП и еще и сломает человеку голову об горутины и асинхронщину. Лучше уж Python, концепции в нем простые и информации о нем намного больше.
Да, можно еще попробовать брать не последний элемент как эталон, как какой-нибудь другой для интереса.
Ну и хорошо бы как-то разумно ограничить число людей, для которых можно предсказывать, на полной выборке могут быть странности (например, можно предсказывать только для людей, которые сделали больше k посещений). Но это лучше уже проводить после оценки качества.
Илья Зенин: можно для этой задачи попробовать так:
берем ряд пользователя и делим на две группы: первые n - 1 элемента - это ряд, по которому будем предсказывать, а n-й элемент - эталонное значение. Предсказываем по n - 1 дату n-го посещения и сравниваем с истинной датой. Если отличается не больше чем на m дней - успех, если больше - неуспех. Проделываем так со всеми пользователями, а потом просто находим долю верных предсказаний. Это и будет измеряемым качеством алгоритма.
Посмотрите курс Воронцова - там много внимания уделено именно проблемам определения качества алгоритма, я привел самый простой способ, который подходит в Вашей ситуации:)
Илья Зенин: если в Вашем случае работают простые мат модели, которые можно подобрать эмпирически (я про них в первой части писал) - это здорово) А какое качество получается, если не секрет?
Алексей П: но не нужно приуменьшать роль языка: если семантика языка подразумевает понимание сложных концепций - вряд ли новичок, который который ни то, что с ними не знаком, а вообще мало что знает, сможет его быстро осилить и писать нормальный код.
golang моден, да. Но, несмотря на кажущуюся простоту, для новичка он не так уж и легок в изучении. Особенно это касается асинхронности и потоков-каналов - для правильного их использования нужен все-таки определенный опыт, который новичку взять неоткуда. Да и дизайн у языка - ужасная императивщина, что явно не плюс. Хотя да, новичку на это по больше части плевать.
Про ноду я мало что могу сказать, но она опять же все из себя асинхронная - человек без понимания классического многопоточного подхода вряд ли поймет преимущества этой парадигмы и правильные сценарии использования.
"Python интерпретатор. Соответственно первый раз вычисление идет медленнее. Следующие разы выполняется уже бай-код." - Вы описали что-то вроде JIT-компилятора, да и как-то не так. В python все проще - сначала компиляция в байт-код, а потом байт-код всегда одинаково разворачивается в машинные инструкции для одного и того же окружения. В случае PyPy (питон с JIT-компилятором) - компиляция в байт код, а затем по ходу работы компиляция участков, для которых это возможно, напрямую в машинный код.
Почему порождается зомби - Вы уже сами выше написали, повторять вряд ли будет иметь смысл)
fork - низкоуровневая операция, которая только усложняет код. В Python есть более удобные механизмы (тот же multiprocess) - в этом случае как минимум не нужно городить проверок на то, в каком именно процессе мы находимся.
Ответ, который предложили на stackoverflow хорош, для той бизнес-логики, которую Вы описали в этом комментарии - такое решение ближе всего к идеалу.
А вот это ни капли не машинное обучение. Машинное обучение - это создание модели, которая может предсказывать результат на основе входных данных. В вашем примере - это херня какая-то, которая может только по заранее определенным параметрам выдать заранее определенный результат.
Я так понимаю, Вы уже достигли максимального уровня, если с уверенностью об этом всем говорите.
А что, простите, включает в себя каждый из этих уровней? За год с нуля быть активным участником разработки javascript-движком? Или участвовать в разработки спецификации? Или хотя бы не задавать вопросы на тостере, на которые можно элементарно найти ответ в поисковике?
По-моему за год с небольшим можно только научится писать более-менее вменяемый код, который уже можно осторожно пускать в продакшен.
А какие варианты то пришли в голову? Мне что-то подсказывает, что намного продуктивнее обсудить имеющиеся идеи, чем ждать, что сейчас тут что-то стоящее возьмут и предложат.
iegor: серьезно? Что у Вас, что у господина lega используются странные костыли для решения простой задачи. Почему просто не сделать, как предлагает господин angru, но не изменять словарь в функции, а возвращать новый экземпляр?
Только слушать 80 порт без root не получится в любом случае. Для ТС идеальным вариантом будет осилить запуск в связке uwsgi + nginx, а там эта проблема решится сама собой.
Мне кажется, что вы нагло путаете понятия IDLE и IDE. А фраза "хороший python IDLE, лично на мое усмотрение, это PyCharm" звучит как "хорошая Лада, лично на мое усмотрение, это БМВ"