В итоге, получилось «система сложная, так давайте сделаем ее простой». Проблема в том, что нельзя из сложной системы сделать простую. Можно покрыть ее слоями абстракции и сказать, что «вот, простая система», а в итоге она будет ее сложнее, чем та, что была до этого.
GitHub бы тогда не работал, он тоже использует amazon.
Тут скорее причина в том, что именно эту версию Amazon CloudFront настроили так, что бы не было доступа с Украины.
А типу на сервера вже взагалі усі забили? Навіщо їх атакувати, так?)
Ви ж розумієте, що атакувати користувацкі машини та вимагати з них 300$ за дані там — немає сенсу.
Повальна більшість людей просто знесе собі систему.
Атакують саме компанії.
Зависит. Я предполагаю, что мне хватит где-то 5к баксов. Вроде вполне реальная зарплата в Украине для какого-то неплохого синьора, нет?
До определенного предела. Если ваша зарплата уже выше ваших текущих потребностей, ее рост вас не будет мотивировать.
Никого никуда не понесло. Алексей 100% прав. Проблема не в теории, а в практике.
Что, правда? Очевидно, что есть 1000 и 1 возможность сделать неправильный agile. 1000 и 1 способ заставить его неправильно работать.
И это все будет отлично согласоватся с теорией. Просто из-за пробелов в теории, которые подразумевают, что все будут делать вещи так, как их предпологал автор.
Проблема то именно в теории. Она слишком пуста.
Тут вот написали, что PM все-таки не руководитель проекта)
К несчастью, практически всем плевать на идеологию. Тулзовины рулят.
Не думаю, что будет существенная разница с таким маленьким размером. Не на Java 1.4 пишите же.
Такие уже есть и они весьма удобные?
Что не так то?)
Абсолютно не важно, OpenCV есть и на Java, и на С++, и на Python.
А еще это может значить, что вакансии по Java быстрее закрывают :)
Их там чаще всего и нет.
Да не налетят сюда ребята из Luxoft.
При прохождении студенческой практики пришлось подписывать то, о чем я не могу говорить, потому что в нем был именно такой пункт.
В некоторых NDA запрещено разглашать о существовании NDA.
С радостью попробую свои силы как Java developer)
Думаю, имелось ввиду то, что из-за присутствия еще одного слоя абстракций (объекты) программа будет работать медленее, чем аналогичная, написаная без них.
С другой стороны, скорость разработки программы без объектов значительно упадет.
Хм, мне кажется, что у вас небольшой конфликт в требованиях:
Продуктивность (это у вас еще и строгая типизация) явно конфликует с простотой синтаксиса. Как я понял из описания языка, то в Nim строгая типизация не обязательна. Это усложняет синтаксис и чтение кода.
Безопасность и скорость. Классическая дилема. Нельзя сделать одновременно безопасный и быстрый язык. Чем-то приходится жертвовать. Меньше проверок — меньше скорости.
Выразительность. Она сразу конфликтует с несколькими пунктами. Выразительные языки проигрывают в скорости и простотой синтаксиса.
Портируемость. Портируемость и скорость совершенно не совместимы, так как там, где можно использовать особенности платформы приходится писать общий код.
К тому же, у ним излишне свободный синтаксис. Если он пойдет в промышленные масштабы, то все станет печально.
Ну, вы перекладываете сложности с кода на архитектуру. Это не решает проблемы сложности. Более того, этот код станет писать более сложно, так как он будет ориентирован на более сложную архитектуру.