Ищу помощи java
Я понимаю, что пикабу для этого площадка не совсем подходящая, но я не знаю куда обратиться, а мне всего то нужно задать пару глупых вопросов :)
Я понимаю, что пикабу для этого площадка не совсем подходящая, но я не знаю куда обратиться, а мне всего то нужно задать пару глупых вопросов :)
Добрый вечер!
Заканчиваю годовые курсы программирования в одном из универов, и настало время писать диплом. Можете, пожалуйста, накидать тем для клиент-серверного приложения(пишу на Java + Spring Web + Hibernate). Нужно придумать что-то интересное для небольшого диплома, но совсем нет идей.
Первый пост на Пикабу, очень надеюсь на вашу помощь.
Спасибо заранее.
Всем привет. Ни для кого не секрет, что лет 15 назад появление кнопочных (тогда ещё) сотовых телефонов с цветными дисплеями, а также новыми мультимедийными возможностями изменило нашу жизнь. Игры на тех телефонах, по сравнению с современными, выглядели очень примитивно. Вот, например, игра Bounce на телефоне, которую многие помнят:
Фото взято из английской Википедии. Но всё же эти простые, с виду, игры должны были как-то создаваться. Для этого в начале 2000 года компанией Sun Microsystems (ныне Oracle) была начата разработка мобильной платформы J2ME, профилей MIDP и CLDC. Задачи ставились простые: развернуть возможность начинающим разработчикам быстро приступать к созданию новых игр и получению за это коммерческой выгоды.
Вспоминается чья-то недавняя фраза из комментариев на Пикабу:
- Что вы знаете о бесполезных профессиях? Расскажите об этом J2ME программисту!
Собственно, вопрос: а как эти самые игры разрабатывались, из чего они состоят?
Каждая игра состоит из системной информации, кода и ресурсов. Первая вещь чисто формальная, а вот вторая и третья нам интересна. Рассмотрим на примере всё той же игры Bounce от Nokia.
Напоминаю, что такие, даже устаревшие игры, могут до сих пор являться чей-то собственностью, поэтому разборка игр на ресурсы и декомпиляция кода не разрешается разработчиками. Материал для данной статьи был взят из интернета для учебных целей.
Итак, вот они, ресурсы:
Эти ресурсы (а конкретно в данном случае - спрайты, из которых составляется игровой мир) вшиты в сам пакет приложения jar. Сами по себе они ценности не представляют. Но байт-код игры, как и любой другой программы, выбирает по очереди эти ресурсы и использует их для создания привычной нам игровой картинки. Помимо ресурсов, в игре присутствуют ещё и уровни. Тут сложнее. Обычный уровень игры выглядит примерно так:
Да, выглядит не особо интересно. Но, если вглядеться, то видно, что разнообразие у значений небольшое - 00, 01, 1D, иногда 6E и прочее. К каждому из этих значений в коде игры ассоциирован свой объект (картинка, фигурка или сущность), которые потом игра расставляет в указанном порядке и формирует тем самым игровое поле или уровень.
Теперь, непосредственно, код. В файле игры содержатся т.н. классы, в них-то и описана сама структура игры и осуществляемые ей действия. Вот, например, таковые в архиве с игрой:
В данном случае игра не была подвергнута т.н. обфускации. Зачастую в 99% всех игр эти классы выглядят уже так:
Т.е. в процессе обфускации названия классов и всех переменных теряются и заменяются на набор букв по алфавиту. Это выполняет две функции: во-первых, уменьшается размер итоговой игры или программы (самая большая по количеству классов j2me программа, на моей памяти, это J2ME SDK - содержит 447 классов), во-вторых, обеспечивает защиту от вмешательства шаловливых ручек навроде моих - разобраться в этом наборе однотипных наименований уже очень сложно - и не всегда поймешь, что имел ввиду автор в том или ином классе. Знает это только лишь он сам. Но вернёмся к нашей игре. Если открыть любой класс, увидим мы немногим отличное от того, что увидели в файле уровня.
Т.е. можно видеть какие-то наименования методов, но в общей картине разобраться трудно. Чтобы превратить этот байт-код в какой-то понятный человеку язык, используется программа - декомпилятор.
- На тот момент, когда эти игры были в ходу и имели коммерческую ценность, декомпиляция наказывалась уголовно (т.к. она могла повлиять на полученную компанией коммерческую выгоду от игры). Сейчас же, думаю, вся возможная выгода уже получена, но на всякий случай если кто-то из разработчиков описанного в посте кода увидит его, прошу меня извинить за рассмотрение именно на этом примере.
Итак, декомпиляторы. Знакомьтесь, их был с десяток: JD, JAD, Mocha, DJ, JD-Core и выпущенный последним и на текущий момент самый совершенный: Fernflower. Файл fernflower.jar можно найти в сети. Чтобы получить исходный код из байт-кода, необходимо сам файл скормить декомпилятору. В данном случае делается это просто: создаётся папка и пишется в командной строке, что делать программе.
И мы получим примерно следующее:
Т.е. вполне читаемый код. В нём уже можно разобрать, что имеется ввиду под каждым действием и для чего нужна каждая переменная.
- Кстати, этот код всё же частично обфусцирован - например, видно переменные с именами var2, var3 и т.п. в оригинальном коде они часто называются типа CurrentBallX, CurrentHeight и др. для того, чтобы можно было понять суть этой переменной.
Но: иметь читаемый код, это не значит иметь рабочий код. В данном случае, с вероятностью в 99% (если программа сложнее HelloWorld) будут также содержаться ошибки декомпиляции. Вызваны они тем, что декомпилятор не всегда понимает, что имеется ввиду автором или самим компилятором. Хотя файл из fernflower на выходе имеет минимальное количество этих ошибок.
У нас теперь есть исходный код игры. На самом деле с этого этапа всё и начинается. Программист в оригинале пишет весь этот код "из головы", т.е. создает и забивает все переменные, классы и методы с нуля.
Теперь перенесёмся в 2007 год. Допустим, вы написали исходный код игры и решили собрать её, чтобы потом отправить на продажу на свой сайт, предложить компании-издателю и т.п. А для этого что вам нужно? Вам нужен компилятор кода и сборщик. В совокупности всё это называется SDK, как и на десктопных вариантах программирования. В качестве IDE с подключаемым java-компилятором можно было использовать Eclipse, NetBeans с дополнительными библиотеками под мобильную версию. А собирать потом или вручную, или внеся свои правки в сборочный скрипт. Но мы рассмотрим один из самых простых вариантов: Для J2ME тоже была своя SDK - которая называется WTK. Последняя версия 2.5.2 была выпущена в сентябре 2007 (том самом, который по мнению многих сгорел). Потом к ней было ещё небольшое дополнение. Вот главное окно программы приветствует нас:
Программа не имеет своего внутреннего редактора кода и на борту лишь простенький эмулятор (который нашу игру не потянет - т.к. написана она была под Nokia). Поэтому для корректной работы нам понадобится следующий софт:
- Сама WTK 2.5.2_01 (небольшой патч 2008 года)
- Java JDK и JRE версии 5.0 (под неё была рассчитана последняя версия WTK)
- Редактор кода (я использую Notepad++, можно блокнот или что удобнее)
- Эмулятор (лучше всего подходит KEmulator Lite v 0.9.8, разработка которого также была заброшена в 2008 году, но на текущий момент он самый проработанный из всех и тянет большинство моделей телефона).
Создаем проект: нажимаем New Project, указываем параметры приложения и путь к главному классу (с которого всё начинается):
Больше ничего не требуется. Окно конфигурации можно просто закрыть, теперь у нас в папке пользователя создана папочка для репозитория приложения:
Общий путь: %папка пользователя%\j2mewtk\2.5.2\apps\
Теперь, чтобы собрать игру, надо наши ресурсы (картинки и уровни, описание меню на разных языках - в крупных компаниях за разработку каждых из них отвечал свой человек) закинуть в папку res. В папку res идёт все кроме META-INF (её программа создаст сама) и, собственно, классов приложения. Классы закидываются в src с сохранением пути.
Содержимое папок src и res. Теперь пробуем собрать игру. Нажимаем кнопку "Build". И видим:
А вот и пошли наши первые ошибки. Сразу аж 12 штук. Теперь уже надо включать голову и разбирать, что же там не так. Начнём по порядку. Откроем строку с первой ошибкой (623) и видим следующее:
На этой самой строчке компилятор в операцию побитного И почему-то засунул японский иероглиф 'ソ'. Понятное дело, что такого быть не может: цифру нельзя объединить с иероглифом. Но с чем же можно? Получим числовой код иероглифа:
В числах это 65407. Именно это число и должно быть в процедуре. Выполним автозамену. Выясняется, что в остальных классах ошибки аналогичные. Итого для трёх разных классов в нескольких местах кода был неправильно распознан тип.
Пробуем собирать:
Теперь ошибок стало.. внимание.. 39! Но ничего страшного в этом нет. Это нормальная практика компилятора - сначала отсеиваются более важные ошибки, затем менее важные. Если разобраться в причине, выясняется, что ругается на то, что не удалось найти некоторые методы, находящиеся в классах, в пакетах, таких как как com.nokia.mid.sound, com.nokia.mid.ui и других. Собственно, а этих классов то тут быть и не должно - они уже содержатся в исполняемой среде (телефон Nokia).
Либо они добавлялись (в те самые золотые года) разработчиками платформ в IDE под конкретные модели телефонов. Кстати, отсюда пляшет несовместимость игр для j2me - именно по этой причине игры от Нокии могли не идти на Сименсе или Эриксоне (вторая причина - разные коды клавиш). Всё зависело от разработчиков и этих самых классов. Но и нам их надо где-то взять для успешной компиляции, т.к. выполнять замену на аналоги из JSR-135 слишком долго. Воспользуемся библиотеками от KEmulator: идём в папку программы, затем папка libs и там есть файл third-party.jar. Копируем его в папку libs нашей программы (в wtk), и удаляем лишнее от других моделей телефонов:
Получили маленький файлик весом в 4 Кб. Можно компилировать:
Теперь осталась одна единственная ошибочка. Снова лезем в исходник:
Компилятор ругается на эту самую строчку. Причем ошибка то и не совсем в ней самой. Тут делается следующее: буфер должен изъять из массива типа Vector какие-то значения и передать их в родительский метод drawImage. Ошибка возникает из-за несовместимости типов: метод drawImage принимает Image, int, int, int, а наш неправильный код, получается, пытается всунуть во 2 и 3 поле объект Integer. Исправляется это тем, что нам нужно забрать значение var2 и var3 из объекта Integer непосредственно. Делается это просто - добавить преобразование типов. Для этого есть метод intValue(). И теперь всё скомпилировалось без единой ошибки:
Поздравляю, мы получили то, что у нас и так было. Вернее, того, чего не было - работающий исходник. Чтобы теперь превратить это игру, к классам нужно добавить ресурсы и это дело собрать. Собирается всё в два клика: Project -> Package -> Create Package. Теперь появились файлы jar и jad в папке bin проекта. Но перед запуском надо сделать ещё кое-что: т.к. мы добавили библиотеки для компиляции, эти самые библиотеки из готового пакета нужно выпилить (в случае подписи приложения сертификатом это надо сделать до подписи). Удаляем библиотеки от nokia, иначе они будут переопределять методы исполняемой среды, а у нас в данном случае это просто интерфейсы, они нам для работы программы не нужны.
Только теперь можно готовый jar-файл запускать на эмуляторе. Закидываем получившуюся программу в KEmulator (или на свой телефон) и наконец-то можно играть:
Артефакты в данном случае вызваны эмулятором (неполной поддержкой тех самых нокиевских методов), а не искажением исходника. На телефоне графика работает отлично. Вот таким вот нехитрым образом производился процесс создания игр в те годы. Я немного застал те времена, хотя и не удалось применить полученные знания на практике ибо всё было вскоре замещено Android и iOS, сама суть при разработке осталось той же, но отдельные элементы реализуются иначе. Надеюсь, теперь вы представляете весь тот труд, что был потрачен на создание java-игр в ту эпоху. Но, всему своё время.
Исходники программы после написания поста были удалены и я не рекомендую получать их образом, описанным в посте.
Всем спасибо, с вами был Kekovsky.
Статей с подобными заголовками существует уже множество. Но в них постоянно какая-то дичь! Смотрите, Google ещё до основных результатов советует такое:
HCL , Карл! Язык, который не просто очень далёк от «Самых Популярных», но ещё и создан для конфигурации, так что его вообще странно ставить в один ряд с языками общего назначения. Страшно представить приключения новичка, который решит строить карьеру по таким советам. Начнём с того, что по запросу «как выучить HCL» вместо туториалов по языку вылезают тексты о соляной кислоте.
Это только одна из многих дикостей, которые я встретил в подобных текстах. Поэтому захотелось объяснить, что с ними не так — и написать собственный текст получше, ссылку на который можно кидать начинающим. Конечно, аудитории Хабра информация для начинающих не очень требуется, зато хабравчане могут дополнить текст в комментариях, сделав его ещё полезнее.
В чём проблемы
Тексты «какие языки учить» зачастую такие слабые, что опытные разработчики разнесли бы их в пух и прах, но опытные разработчики их просто не открывают. Их открывают новички, у которых нет компетенции, чтобы заметить подвох. В результате новички доверяют всякой ерунде, а проблемы в текстах остаются незамеченными и процветают. Что именно это за проблемы?
Проблема первая: отсутствие содержания. Похоже, иногда эти тексты пишут люди, не имеющие о программировании никакого представления, и они ухитряются писать целые абзацы, в которых не сказано вообще ничего.
Пример: «На сегодняшний день многие студенты выбирают JavaScript в качестве проводника в мир технологий. И правильно делают, ведь человек, знающий JavaScript, вряд ли останется без дела. Популярность и практичность этого языка позволяют ему занять одно из лидирующих мест в списке языков, необходимых к изучению.
Однако также стоит учесть, что JavaScript – это один из наиболее популярных языков программирования. А это значит, что на него существует как достаточный спрос, так и огромное количество предложений. Поэтому если вы изучаете или хотите изучить этот язык, то постарайтесь максимально в нем разобраться и стать отличным специалистом».
Проблема вторая: закидывание читателя мелочами без объяснения главного.
Представьте, что человек захотел впервые купить автомобиль. Он ещё не вполне понимает, какие есть варианты кузовов, приводов и коробок передач. А ему с ходу вываливают список из десяти машин, где смешано в кучу всё: внедорожники, малолитражки, грузовики. И вместо пояснений о том, в чём их принципиальные различия, пишут набор разрозненных фактов вроде «у этого автомобиля есть защита картера». Сильно ли это поможет человеку?
А с текстами о языках происходит именно так. Похоже, когда кому-то ставят задачу написать про них, зачастую автор гуглит по пять случайных фактов про каждый и уверенно идёт за гонораром.
Пример: «Go использовался для создания Ethereum». Что, серьёзно, вот это самая важная информация про язык (когда речь идёт не о Solidity)? Вот она поможет сделать правильный выбор?
Проблема третья: сообщают вещи, которые начинающим попросту ничего не скажут.
Пример: «Недостатки Python: нет таких модификаторов доступа, как protected, private и public».
Так и представляется картина маслом. Школьница Василиса Пупкина, ещё почти ничего не понимающая в программировании, пытается выбрать себе первый язык. Читает такое описание и говорит: «а, ну раз нет модификатора protected, конечно, я предпочту C#». Ну камон, неужели не ясно, что подобная информация даст Василисе только ощущение «всё это программирование непонятная хрень, лучше послушаю песню "Валенки"»?
Проблема четвёртая: бездумное следование рейтингам популярности языков. «А-а-а, Go поднялся в индексе TIOBE на несколько строчек, срочно учим его!» Ну слушайте, а ещё по TIOBE получается, что обучающий язык Scratch обошёл Dart — и что теперь, дартовикам надо срочно перейти на детский язык, что ли?
Все эти пузомерки очень условные: результат зависит от того, какую метрику использовать. Поэтому не надо молиться на конкретные места в рейтингах, будто это какая-то спущенная свыше истина. Да, популярность языка имеет значение (по популярным больше справочного материала и вакансий), но не требуется разбираться «какой самый главный в мире», из ряда самых известных подойдёт любой. А чтобы найти эти «самые известные», не требуется лезть в рейтинги, они и так на слуху.
Пример: «В некоторых списках Python фигурирует на 5-ом месте, в других его ставят на 2-ое».
Проблема пятая: за всем перечисленным порой забывают про области применения, а для новичков это может быть важнее всего. Представим, что школьница Василиса, которая каждый день пользуется кучей мобильных приложений, захотела сделать своё собственное. Какая ей тогда разница, какие модификаторы доступа у Python, кто кого обошёл в рейтингах и на чём написан Ethereum? Всё, что ей надо знать — на чём пишут для iOS и для Android.
Поэтому вот текст, который пробует от всего этого уйти:
Вступление
Дорогой читатель! В интернетах можно увидеть прорву дискуссий, где опытные разработчики спорят, какой язык лучше всех. Не надо вестись на это: лучшего нет. Разные лучше подходят для разных задач и людей.
Поэтому для начала надо понять свои задачи. Из-за чего вообще встал вопрос выбора языка? Захотелось делать что-то конкретное (игры, сайты, мобильные приложения)? Или важно как можно скорее получить работу в IT любой ценой, что бы ни пришлось кодить? Или хочется просто попробовать «посмотрим, интересно ли мне окажется, а там как пойдёт»?
Если хочется заниматься чем-то определённым — тогда важнее не теоретические сравнения языков, а то, какие используются конкретно в этой области. Часть информации об этом можно получить из текста ниже, но есть смысл и погуглить «what languages are used for %интересующая_область%».
Если важно как можно скорее пройти путь до получения работы, тогда тоже важнее текстов-сравнений может оказаться другая вещь. Стоит посмотреть на сайте вроде HeadHunter вакансии Junior-разработчиков своего города: какие языки чаще всего упоминаются в них?
А если нет ни спешки, ни определённого запроса, тогда спрошу так: есть ли потребность делать что-то такое, что пользователь видит глазами? Работа над веб-сервисами делится на фронтенд и бэкенд. Грубо говоря, фронтенд — это «что видно в браузере», а бэкенд — это «что выполняется далеко на сервере, чтобы фронтенду было что показывать». Когда пользователь нажимает на кнопку, её поведение прописал фронтендер — но если это кнопка «перейти к диалогу» и надо показать историю переписки, то дальше бэкенд извлечёт сообщения из базы данных на сервере.
Так что разработчикам-фронтендерам при работе над кодом приходится задумываться о том, как выглядит пользовательский интерфейс, а вот бэкендерам — только непосредственно о коде. Кому-то близка визуальная сторона и хочется показывать пальцем «смотри, мама, вот это добавил я» (для этого подходит фронтенд или мобильная разработка), кому-то больше нравится иметь дело с внутренней логикой, чем с «кнопочками». Так что если уже есть понимание, что ближе, это может помочь с выбором.
А вот теперь можно читать про конкретные языки и решать, какой из них соотносится с личными целями. Расположил популярные языки по хронологии, в порядке их появления:
C (1972) и C++ (1985)
C++ изначально появился как развитие языка C, поэтому я объединил оба в одном пункте. Можно сказать, что это дедушка и отец остальных языков в этом списке: они здесь старше всех и очень повлияли на другие языки.
Сейчас они выглядят не точно так, как в момент появления (у C++ каждые три года принимают новый стандарт, недавно был принят C++20), и с годами всё сильнее различаются. Но идеи, заложенные ещё в начале, продолжают накладывать свой отпечаток. Когда создавался C, компьютеры были куда менее производительными, так что их ресурсы приходилось экономить куда старательнее. И тогда всё было «ближе к железу»: программирование в большей степени, чем сейчас, требовало понимать, как физически работает компьютер.
В результате теперь по сравнению с более современными языками у С и С++ репутация «хардкорных»: требовательных к программисту, зато позволяющих выжать из железа всё. И зачастую используют их как раз там, где действительно нужно выжимать как можно больше: например, в играх. Или в софте не для привычных компьютеров, а для различных других устройств, в которых зачастую маломощные процессоры — от автомобилей до банкоматов.
Раз всё сложно, в чём смысл делать подобное своим первым языком? Тут мнения разнятся. Многие считают, что действительно лучше начинать с чего-то полегче. Но есть и такая позиция: при изучении таких языков лучше понимаешь, как работает компьютер и исполняется код, а это для программиста очень полезно. В общем, можно посоветовать тем, кто не ищет лёгких путей, а хочет понять всё поглубже.
Python (1991)
В каком-то смысле Python — противоположность C: если там «сложно, зато производительно», то здесь «просто, зато к производительности есть вопросы».
Такое категоричное заявление требует уточнений. Во-первых, о простоте: свои хитрости здесь тоже есть, но они не так болезненны для новичков. С какими-то языками сразу врезаешься лицом в стену из непонятных терминов и теряешь всё желание что-то делать, а здесь начинаешь с куда более простого и понятного кода. Для многих базовых задач предоставлены встроенные способы решения, Python называют «языком с батарейками в комплекте». Неудивительно, что его часто рекомендуют в качестве первого языка, и он стал очень популярен в образовании.
Что же до производительности, то Python действительно проигрывает и C++, и многим другим языкам. Но порой его называют «медленным» презрительно, а вот это уже зря. Вспомним слова о том, что языки хороши или плохи не сами по себе, а применительно к задачам. Да, есть задачи, для которых Python не подойдёт — но есть и такие, где разница в скорости между ним и другим языком вообще не будет заметна. У Python есть свои области применения, для которых он достаточно хорош.
Что это за области? Ещё давно Python полюбили учёные — и теперь с его помощью занимаются такими околонаучными вещами, как машинное обучение и data science. В бэкенде веб-сервисов его тоже используют. Про образование уже сказано. А помимо разработки, его любят в системном администрировании — там он отлично подходит для мелких утилит.
Вакансий с упоминанием Python много, но здесь есть нюанс. Порой этот язык называют «вторым лучшим для любой задачи»: всегда удобный вариант, но всегда уступающий чему-то. Из-за этого Python зачастую используют не как основной язык какого-то проекта, а «в дополнение». Поэтому в части случаев может получиться, что в вакансии он вроде и упомянут, но не как основное требование, а как бонус — и его знания недостаточно, чтобы откликнуться на неё. Так что для первых этапов обучения он точно подходит хорошо, а вот насчёт трудоустройства смотрите ситуацию в своём регионе.
JavaScript (1995)
Если в бэкенде разные языки активно конкурируют, то с фронтендом всё проще: там господствует JavaScript. Так что, если вам интересна конкретно эта область, выбор первого языка очевиден. А из-за такого доминирования востребованность языка гигантская, количество вакансий очень большое — так что с точки зрения трудоустройства это тоже хороший вариант.
JS считается относительно простым языком для обучения. Но стоит учесть, что во фронтенде сейчас почти никто не использует «просто JavaScript», нужно будет ещё освоить один из популярных фреймворков (а также научиться пользоваться инфраструктурой). И вот к ним нареканий о сложности заметно больше — так что по пути к карьере фронтендера боль может возникнуть на этом этапе.
При популярности JavaScript и у него, и у всей современной фронтенд-разработки хватает ненавистников. Кто-то говорит, что во фронтенде всё постоянно меняется и надо постоянно переучиваться вместо спокойной работы (правда, в 2020-м таких жалоб уже заметно меньше, пик остался в прошлом). Кто-то жалуется на странности в логике JS. Во многом такие оценки субъективные, их не назвать «правильными» или «неправильными» (одно и то же кого-то злит, а кого-то радует) — так что неизвестно, что будете ощущать лично вы.
Помимо фронтенда, JavaScript используют и в других областях (бэкенде, компьютерных программах, мобильных приложениях и не только), но в них он от господства далёк.
Java (1995)
Не стоит думать, что Java имеет какое-то отношение к JavaScript — хотя названия похожие и языки были представлены миру в один год, они совершенно разные, и сходство названий объясняется сугубо историческими причинами.
Java используется в первую очередь в бэкенде, и хотя не царит там безраздельно, как JS во фронтенде, позиции очень хорошие. Порой можно услышать пренебрежительное «да она уже устарела и вот-вот умрёт». Ну, во-первых, скажу так: эти слова звучат уже лет дцать, а она что-то никуда не делась. Мы в JUG Ru Group проводим конференции по разным языкам, и по Java получаются самые посещаемые, в прошлом году собралось больше 2000 участников — это никак не выглядит смертью.
А во-вторых, даже если исходить из того, что когда-то она умрёт, это не значит «учить её сейчас бессмысленно»: простой инерции явно хватит ещё настолько, что скорее вы сами захотите переключиться на что-то другое, чем придётся делать это вынужденно.
Другая популярная претензия к Java — мол, она «скучная и многословная», и используют её скучные компании вроде банков, а какие-то другие языки позволяют реализовать то же выразительнее и лаконичнее, и их ценят в весёлых стартапах. Ну, тут всё тоже субъективно, как с JS: знаю многих людей, которые говорят о Java с огнём в глазах и видят в банковской разработке множество интересных задач, но если для кого-то скучно, с этим не поспоришь.
C# (2000)
Когда компания Microsoft представила C#, многие назвали это «ответом Microsoft на Java». Разумеется, между этими языками хватает различий (и за прошедшие 20 лет их число лишь увеличилось), но некоторая перекличка действительно есть, и знание любого из этих языков помогает быстрее освоить другой.
Изначально самая заметная разница была не в самих языках (в синтаксисе или рантайме), а в сферах их применения. Microsoft создал C# как часть своей платформы .NET, связанной с Windows. И если нужно было сделать программу для Windows, то напрашивающимся вариантом выглядел .NET. А вот если такую программу, чтобы запускалась и на Windows, и на Linux, и на Mac — тут могла помочь Java.
Но с годами ситуация изменилась: у .NET появилась новая версия .NET Core, уже не привязанная к конкретной операционной системе, а люди стали реже устанавливать программы на компьютер и больше делать в браузере. Это отчасти сблизило сферу применения языков: если посмотреть сейчас вакансии с названием C#, там, как и у Java, часто будет написано что-то вроде «Построение бэкенда для веб-приложений».
Впрочем, это не единственный вариант. В играх на движке Unity тоже используют C#, а это самый популярный движок в мире — так что в геймдеве язык тоже активно представлен (в отличие от Java).
Kotlin (2011)
Этот язык создала в Санкт-Петербурге компания JetBrains. Он совместим с Java, поэтому Java-проекты можно постепенно переводить на Kotlin: не переписывая всё разом, а постепенно добавляя туда Kotlin-код. И многие попробовавшие его Java-разработчики захотели к нему перейти, ощутив, что тут нет «скуки и многословности», всё выразительнее и современнее.
Пока что язык покорил одну конкретную область: разработку приложений для Android. Изначально их писали на Java, но в последние годы начался массовый переход к Kotlin, он стал новым индустриальным стандартом. Поскольку никто не хочет просто выбрасывать уже написанное раньше, сейчас во многих приложениях есть код и на Java, и на Kotlin, поэтому сегодня Android-разработчику желательно знать оба языка. Но похоже, что в будущем будет достаточно Kotlin — уже сейчас во многих Android-вакансиях упомянут только он.
JetBrains совершенно не хотят останавливаться на Android и метят с Kotlin в самые разные ниши, даже те, где не представлена Java. Каких-то успехов в этом компания добивается, с каждым годом язык становится популярнее, но от других вроде той же Java пока что сильно отстаёт, и насколько ещё ему получится вырасти — открытый вопрос. Так что, если учить Kotlin, в Android-разработке это точно очень пригодится, а в других областях — как повезёт.
Swift (2014)
Наконец, самый молодой язык из перечисленных — он был представлен меньше шести лет назад. Обычно за такое время языки не успевают стать достаточно популярными для попадания в такие списки. Но здесь ситуация особая: компания Apple, создавшая его, ясно дала понять, что теперь iOS-приложения надо писать на нём. А тут как Apple скажет — так и будет, свою платформу компания контролирует.
Но вот всё остальное в мире компания Apple не контролирует. Поэтому, хотя в принципе этот язык можно использовать и для других целей, больше его не применяют особо нигде. Есть попытки серверного использования, но по сравнению с основными бэкендными языками это всё кошкины слёзки.
И в итоге выбор получается совсем простой. Хотите писать приложения для айфонов (ну или для Mac, Apple TV, Apple Watch) — учите Swift. Не хотите их писать — не учите Swift. Ну, если хотите делать приложения «для iOS и Android сразу», существуют ещё кроссплатформенные решения вроде Flutter, но они куда менее популярны.
Прочие языки
Молодые: Go, Dart, Rust и так далее
В интернете легко встретить заявления о том, как прекрасен какой-то молодой язык («молодой» в этом контексте может значить около десяти лет). Мол, он исправляет ошибки предшественников, соответствует духу времени и делает разработку куда приятнее.
Охотно верю, что в заметной степени это правда. Но есть проблема: почти все такие языки используются в индустрии заметно меньше тех самых «предшественников». Так что даже в Москве такой выбор резко сужает круг вакансий, а если вы в городе размеров Омска, то Rust-вакансии вряд ли встретите в принципе. Конечно, можно искать удалёнку, но для первой работы это не лучший вариант.
И какие из этих языков со временем по-настоящему расправят крылья, а какие останутся нишевыми или вообще завянут — сказать сложно. А значит, учить такой язык — это отчасти лотерея. Думаю, что начинать разумно всё-таки с проверенного временем языка, а к «стильному, модному, молодёжному» переходить позже, уже хорошо понимая, что именно делаешь и зачем.
Высокооплачиваемые: Scala, F#, Haskell и так далее.
Также в интернете можно встретить сравнения зарплат. Обычно из них следует, что больше всего получают разработчики, которые пишут на языках функциональной парадигмы.
Ну, можно гнаться за длинным долларом, но тут подстерегают сразу две ловушки. Во-первых, то же маленькое число вакансий: может оказаться, что вроде как можно заработать большие деньги, только вот негде. А во-вторых, хочется заметить, что обычно эти языки осваивают опытные разработчики, уже овладевшие ранее другими. И поэтому возможен такой эффект: высокая оплата вызвана не самим языком, а опытом разработчиков. Так что, если вы выучите такой язык, но опыта вам не хватает, то не начнёте сразу же магическим образом зарабатывать на уровне ветеранов.
Узкоспецифичные языки: SQL, HTML, Bash и так далее
Упомяну для полноты картины. До этого речь шла о языках общего назначения, на которых гипотетически можно писать что угодно. Но существуют ещё языки, используемые строго для конкретного круга задач. Например, SQL используется конкретно для работы с базами данных. И его знание вам может понадобиться «в дополнение» к вашему основному языку.
Не требуется бросаться учить все такие заранее, до возникновения какой-либо потребности в этом. Но чем больше вы о них знаете, тем лучше.
Заключение
Если о разработчиках что-то известно достоверно, то вот что: они любят дискутировать о языках программирования и часто расходятся во мнениях.
И к этому посту почти наверняка появятся комментарии, что в нём многое некорректно, упущено что-то значимое и вообще надо было всё написать иначе.
Что если я заявляю «надо объяснять главные различия», то надо было обязательно рассказать про типизацию.
Что где-то я забыл упомянуть важнейшую область применения.
В общем, очень вероятны критические комментарии — и это замечательно: в одиночку сложно объять всю индустрию, так что чем больше людей с разным опытом дополнят текст своим видением, тем более полной окажется итоговая картина. Я даже намеренно упустил один популярный язык, про который недостаточно знаю, чтобы хорошо его описать — думаю, его сторонники сами придут в комментарии и восполнят пробел.
Статья рассчитана на начинающих изучать то или иное направление в программировании и думает с чего начать.
В общем классная статья.
Привет. Я занимаюсь вёрсткой сайтов, но вот у меня недавно появилась идея для приложения. Я хочу понять, если я буду заказывать у каково-то андроид разработчика это приложение, как я могу быть уверен , что он не украдёт мою идею или не сплагиатит её? У кого есть опыт разработки своего приложение, подскажите пожалуйста , что делать новичку в этой области? Заранее спасибо.
Пс шутники или ещё какие-нибудь "остряки" не засоряйте все тут
Я какое-то время изучала Java, а сейчас приняла решение перейти на мобильную разработку на Swift. У меня было оплачено обучение и сейчас идёт тема «Архитектура и шаблоны проектирования на Java». Так вот вопрос таков: похожи ли в плане архитектуры Swift и Java? Стоит ли тратить время на изучение этого курса, если Java я уже не буду использовать, и может ли мне пригодиться эта тема потом в изучении Swift? Не смогла найти в интернете какую-либо информацию по этому вопросу, но знаю, что здесь сидит много опытных программистов, знающих по несколько языков.