Войти в IT: что нужно знать и где изучать

@sergturi, Golang, имхо конечно

@rooty, Как вариант :)

@sergturi, Ada или Rust /s

@nakopylov, для выпускников физмат Haskell подойдёт как первый язык :)

@sergturi, а чего не лисп? ))))))))

@nakopylov, BrainFuck $)

@rooty, не надо голанг новичкам

@sergturi, по моему мнение самый лучший начальный яп это Java. Причем я не буду говорить для кого. Ну например если хочется вкатиться в конкретную область то понятное дело там есть свой набор яп для этих целей. А если хочется с чего то начать именно попробовать покодить то Java вне конкуренции по ряду причин:

• строгость. ЯП бьет по рукам и не дает делать откровенную дичь.
• статическая типизация. Новичку в десятки раз проще понять что вернет функция или что лежит в переменной, если это явно написано.

-компиляция. Не валидный код не собирается.

• золотая середина между сложными более низкоуровневыми языками и чрезмерно сахарными более высокоуровневыми.
• возможностей ровно столько сколько нужно. Есть в принципе все что нужно.
• отличная стандартная библиотека
• наверное одни из топовых возможностей легко изучать исходный код в процессе. В подавляющее большинство функций и классов можно провалиться и просто посмотреть как оно сделано, причем все это работает быстро в IDE, исходными очень хорошо документированы. Нативные функции редки.

Прощу заметить что в данном коменте я имею ввиду Java не как ЯП(который в принципе не плох) а как ЯП для обучения(в чем он топ). Проверял на определенном количестве людей в контексте: Java vs С#, Java vs JS, Java vs Python.

PS
С# - отличный ЯП но очень переусложненный и неудачно засахаренный.
Golang - отвратительный ЯП, в плане обучения из-за своей простоты одновременно и хорош но и также имеет много сложностей в силу грубости и примитивности. Все такки не советовал бы.
JS - как первый ЯП == сломанное нормальное представление о правильности.
Python - из-за своей динамической природы допускает огромное число ошибок. Во многом вопреки своей репутации очень непредсказуем. Нет сборщика из коробки. Половина кишок написаны на С в силу чего невозможно нормальное изучение по исходникам.
PHP - божеупаси :)

@sergturi, Turbo Pascal

@Lewigh, Спасибо за развернутый ответ.

С технической точки зрения я согласен на 100%. Безусловно, можно начать с Java, но порог входа будет выше чем в Python. На Java разработка и отладка занимает больше времени чем на Python. Я не говорю о качестве конечного продукта (на Java оно, конечно, выше) но есть business needs. Практики показывают, что на Python разработка дешевле.

То что Python допускает много ошибок, для новичков это плюс. По началу можно писать откровенную дичь, развиваться и осознать что есть Java, Kotlin, Swift.

@sergturi,

Практики показывают, что на Python разработка дешевле.

А давайте посчитаем сколько по времени занимает разработка фичи. В это время входит:

1. Время на разработку задачи аналитиком и утверждения разработкой.
2. Время на разработку.
3. Время на написание тестов и проверку перед передачей на кодревью.
4. Время на кодревью и передача в тестирование.
5. Время на тестирование задачи.
6. Время на исправление багов из текущей фичи.
7. Время на перепроверку задачи.
8. Этому всему прибавим время на общение с аналитиком/заказчиком.

Как можно заметить, разработка - это только 1 пункт из 8.

Теперь разберем от чего зависит время непосредственной разработки:
-архитектура проекта. Чем качественнее написан проект, тем дешевле добавление фич. Чем нестабильнее проект тем добавление бага или фичи затрачивает больше времени.
-наличие нормальных тестов
-наличие отлаженных процессов
-наличие хорошей коммуникации
-наличия документации

И уже теперь давайте сравним насколько яп помогают или мешают скорости разработки.
В чем Python сейчас может дать лучшие результаты по скорости?

• не нужно объявлять типы - сомнительная экономия, темболее что в современном питоне как я понимаю типы добавлять все-таки рекомендуют.
• объем и читабельность кода- аргумент был бы актуальным лет 10-15 назад. Сейчас уже не так.
• отладка через REPL? Ну тоже какие преимущества по сравнению с нормальным дебагом?

А теперь Java. Нужно писать чуть больше кода за счет типов и тратим время на компиляцию.
Но за счет статической системы типов и проверки на этапе компиляции мы получаем:

• отсутствие необходимости писать тесты на типы
• отлов огромного числа ошибок во время компиляции, за счет чего сокращаем как время разработки так и пункты 5,6,7. Так как вероятность в более строгом языке передать на тестирование дефектную фичу - меньше.

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

Мнимая экономия на времени передачи задачи в тест часто будет с лихвой проседать на тестировании и багах.

Там где одно выигрывает другое проигрывает. Про выигрышь или проигрышь на дистанции на больших проектах и говорить не буду.

То что Python допускает много ошибок, для новичков это плюс.

Если человек сразу научился не правильно его потом чертовски трудно переучивать на нормально. В любом деле поначалу нужно страдать чтобы потом преуспеть.

@Lewigh, на вкус и цвет все фломастеры разные. Пытался учить Java - в итоге забил и потерял 5 лет.

Начал учить Python - второй год пишу, полет прекрасный.

Новичкам полезно научится пользоваться тайпхинтами и дебажить код. Да и врятли они будут писать настолько большие проекты, где статическая типизация критична.

@Lewigh,

С# - отличный ЯП но очень переусложненный и неудачно засахаренный.

triggered

Имхо, нормально он насахарен. Когда в мир JVM принесли шарповый сахар и назвали это Kotlin - этим стало возможно пользоваться.

Java сама по себе же очень многословна и заставляет тебя писать кучу ненужно бойлерплейта.

По поводу обучения с Java vs обучения с C#.

На своём опыте могу описать. Я пытался начать с Java, т.к. более распространена и найти работу проще. Но в итоге не осилил стартануть с неё. В мире Java как будто бы обязательно СНАЧАЛА знать кишки, а потом уже писать простейший хелло ворлд.

Если консольное приложение написать ещё более менее (хотя я помню, как в своё время гуглил кучу готовых хелловорлдов из интернетов и они у меня банально не компилились и я не мог понять почему), то вот Spring без понимания кишок можно замучаться отлаживать. Может с развитием Spring Boot это стало чуть проще, хотя всё ещё (имхо) очень неинтуитивно.

В итоге я стартанул с шарпа. И что консольные приложения, что WinForm, что WPF, что ASP.Net - в инетренет было тонны пошаговых инструкций для тупых, да и сам процесс написания кода казался более интуитивным и очевидным. Казалось я мог нажать точку и предположить название метода и он и правда там оказывался и было интуитивно понятно как этим пользоваться. В итоге в качестве диплома я написал полноценный сайт аля онлайн платформа для оценки фильмов и прикрутил туда рекомендателку нейросеть и всё это на шарпе.

P.S.: В мир Java я перекатился только спустя 3 года работы на шарпе и только потому что бОльшая часть продуктовых приложений всё ещё пишется на Java и мир JVM как будто бы игнорирует тот файт, что Шарп уже 100 лет как кросплатформенный и не завязан более на винду :(

@MrModest,

Имхо, нормально он насахарен.

Нет не нормально. Можно красиво встраивать новые фичи в какую никакую философию использования языка, строить вокруг определенных идей и пытаться сделать интуитивно понятными и связанными(привет Kotlin). А можно делать как разработчики языка C# - просто пихать максимальное количество фич каждый релиз на похрен, нужны они или нет. Посидеть подумать как это встроить так чтобы людям было очевиднее и проще запомнить? Пфф, зачем им это, будем на право и налево добавлять новые ключевые слова и комбинировать в миллионе вариантов старые. И получается - помойка фич. Вроде круто, можно из этого чемодана что угодно достать для своей задачи, но вот только все это добро разрозненное в голове держать - такое себе, молчу про новичков, которым с каждым годом все веселее и веселее этот яп учить из-за его бесконечного набухания.

Когда в мир JVM принесли шарповый сахар и назвали это Kotlin - этим стало возможно пользоваться.

Слава богам, Kotlin это именно что не "шарповый сахар" а идеи, в том числе в большем числе из C#, оформленные в тот самый "сахар" нормальным образом.

Java сама по себе же очень многословна и заставляет тебя писать кучу ненужно бойлерплейта.

Не нужно транслировать мифы 20 века. Подключаем библиотеку Lombok и Java становиться во многих местах даже стройнее C#.

В мире Java как будто бы обязательно СНАЧАЛА знать кишки, а потом уже писать простейший хелло ворлд.

Удивительно такое слышать в сравнении с близкородственным яп C#, который построен в большинстве своем на тех же рельсах из виртуальной машины, С-подобного синтаксиса и вплоть до идентичных названий классов в stdlib. Почему в Java нужно знать кишки а в C# нет, загадка.

Spring без понимания кишок можно замучаться отлаживать
WinForm, что WPF, что ASP.Net

Ну это конечно очень объективно сравнивая яп сравнивать не сами яп а библиотеки.
Ну давайте пойдем дальше - Unreal engine лучше подходит для серьезных проектов чем Unity, следовательно - C++ лучше C#. Все же логично, да?. :)

мир JVM как будто бы игнорирует тот файт, что Шарп уже 100 лет как кросплатформенный и не завязан более на винду

Как Вы правильно заметили, мир JVM как то не особо замечает мир .Net. В реалиях жизни под Java уже давно все процессы заточены, джуна вырастить быстрее в силу того что Java более просто яп при этом позволяющий выполнять те же задачи.
Зачем кому-то переходить на .Net если он не дает каких то критических преимуществ? Не нравиться отставание и многословность Java, есть альтернатива Kotlin/Scala. Все инструменты и подходы уже есть. (это я если что Java не хвалю а объясняю текущее положение дел)

Ну за это можно спасибо сказать умным ребятам из Майкрософт, которые из-за своей жадности и наплевательского отношения к пользователям их продуктов, до последнего толкали винду в качестве единственной безальтернативной платформы. Какие там 100 лет, проснулись , если не ошибаюсь только в 2016 году, а это по меркам IT - вчера.

@sergturi, очень смелое заявление. И много людей сходу в автоматизацию заходит?) Чаще всего заходят как обычные QA manual, а потом учатся писать тестики. Хотя снова же написание автотестов и написание программ стоят не так чтобы близко. На джуна QA automative пройти возможно и сможет, но это будет сильный даунгрейд по ЗП

@ApoloSeR, У меня сейчас в команде несколько джунов, всё, почему то, как один говорят что зарплата не важна, главное опыт ☝️.

У джунов зарплаты примерно одинаковые. Есть конечно небольшая разница, но +/- одинаково.

@sergturi, опыт, который ты будучи QA automate получаешь не сильно релевантный относительно опыта разработчика. Что они скажут что-то другое я кстати сильно сомневаюсь) Слушать конечно важно, особенно когда ты их растишь, и на старте опыт важен, это так.
Проблема в том что опыт на хлеб не намажешь и вопрос компенсации так или иначе всплывет (как часто в айтишечке любят зпшчки апать, особенно с ростом грейда, думаю напоминать не стоит))
Главное чтобы вектор был верный и не было иллюзий вроде - "я сейчас стану QA automate, а потом сразу software engineer"

@ApoloSeR, Ну я зашел. Вначале искал работу программистом (питон/js/java - одинаково их знал, точнее не знал). Свою первую работу в it искал, отмечу. Предложили вначале актуализировать старые тесты, а потом уже сам с нуля внедрял автотестирование в проекты. теорию тестирования изучал уже по ходу работы. Платили мне поначалу как и ручникам, потом больше, потому что перерос понятие "тестировщик". В прошлой конторе и в текущей моя ЗП не отличается от программистов.
Вообще, мысль что QA-инженер должен зарабатывать меньше программиста - очень странная и явно устаревшая. Тестировщик - да, он зарабатывает меньше, но только тестировщиком я считаю человека, который просто проходит тесты. А как только его в обязанность начинает входить "обеспечение качества", то и его полезность, а также ЗП, существенно растут