Разница в активном использовании консоли и в заточке стека разработки под Unix системы. В рамках троллинга можно предсказать поиск Visual Studio подобной IDE для Haskell.
Есть уроки по установке Linux. Если вы в Питере - приходите, помогу поставить.
У Linux и MacOS есть несколько удобных фич с точки зрения разработки - пакетные менеджеры, удобная консоль, и Unix-style в проектировании ОС. Рекомендую научиться пользоваться одной из этих систем.
Саратовский Государственный Университет имени Н.Г. Чернышевского. Алгоритмическая школа неплохая. Еще можно в политехнический университет в том же городе.
По кафедрам не подскажу.
Из личного опыта - получение специальности "Программист" не обязательно для работы в сфере IT. Все зависит от желания, навыков и времени, потраченного на получение знаний и навыков. Но если есть возможность - стоит учиться.
Корреляцию между школьной математикой и программированием не заметил, однако напомню слова Ломоносова "Математику уж затем учить надо, что она ум в порядок приводит". Программирование - это умение манипулировать абстрактными моделями по определенным правилам и умение выводить эти правила, в этом оно сходно с математикой. Если у вас есть проблемы с этим - это может стать существенным препятствием. Успокоить вас может тот факт, что математику в большинстве школ преподают весьма отвратно.
На Java можно написать сервер игры. Питону он уступать будет очень врядли. Плюсам - смотря кто пишет на Java и на C++.
Клиент игры на Java можно написать под Android, ежели будет желание.
Всегда есть нюансы. Их много и разных. Самый важный -
По факту - если вы хорошо знаете C++ - Java учить для написания игр смысла нет - вы всегда можете заняться клиентской частью.
Потому что это не совсем так. Сервера многих игр пишутся и на Java в том числе. C++ популярен только в разработке клиентской части, и то не то что бы прям не было других вариантов. Та же Eve Online активно использует Python в разработке клиента. Многие старые игры написаны были на Delphi, С и других языках.
Это называется Escape Analysis. Вроде бы. Основная идея в том, что если объект не выходит за пределы метода в котором он создается - его можно представить в виде набора полей на стеке, а не выделять память под него в куче - скаляризировать. https://habrahabr.ru/company/jugru/blog/322348/
Антон Иванов: Все зависит от вашего флоу. Вы можете подтягивать данные из XML. Или явным образом создавать в коде соответствующий объект.
Честно говоря, у меня не совсем правильный мок получился. В идеале, он должен всегда возвращать статические данные в рамках одного кейса.
Кроме того, может вам с юнит тестов стоит переключиться на функциональные? Может тогда будет проще протестировать необходимый флоу?
Rou1997: Нет. C++ не оптимален в данной задаче. Оптимальна для данной задачи БД. Что же касается противостояния C++ vs Java - попытки осветить его есть в этом видео. https://www.youtube.com/watch?v=dx_6oVFuP8Y
Оно достаточно любопытное, на мой взгляд, рекомендую посмотреть, если вы плюсовик. Заодно расскажете, как решить проблемы описанные в этом видео - будет любопытно почитать.
rishatss: А в каком виде оно приходит с GUI? В виде строки? Если да - то какие проблемы? Если не в виде строки - что то не так в датском королевстве, если доменное имя получают не в виде строки.
Может как то так?
String domainName = jtextField1.getText();
InetAddress address = InetAddress.getByName(domainName);
jTextField.setText(address.getHostAddress());
Рекомендую остановиться, подышать, подумать и прочитать нормальную книгу. Раньше такой книгой была Thinking in Java. Сейчас возможно пригодится Java for Impatient. Как мне кажется, у вас явные пробелы в понимании происходящего.
А вы уверены, что вам нужен именно фриланс, а не просто удаленная работа? Определенная разница таки есть. И в чем проблема работать в офисе по выбранному направлению?
А вы можете приложить вывод Gradle с включенными опциями --stacktrace и --debug? Выложить его стоит на pastebin или аналогичном сервисе.
Кроме того, стоит выключить инкрементальную сборку и произвести сборку с нуля.
