Pull to refresh

Comments 99

UFO just landed and posted this here
Я вот с какойто стороны тоже согласен с утверждением, но статья совершенно тему не раскрывает, скорее какието рефлексии по поводу 'ой какие классные программки можно делать'

Очень просто — Java код компилируется в Java Script, а затем уже этот, родной для браузеров язык, оживляет клиентскую часть вашего приложения. То есть нет необходимости учить что-то, кроме Java. А вот в глубины понимания происходящего в браузере и между ним и сервером, вам погружаться придётся.

А можно ненадо так делать? :))
И Java, благодаря своему всепроникающему наследию, даёт вам возможность опускаться в любые глубины, вплоть до непосредственного общения с железом

мое любимое (с тех времен когда я еще на яве писал), давайте пример программирование bluetooth не под андройд, посмеемся над проникновением в любые глубины
===
я вот явой очарован во многом в том что она системности в мозгах прибавляет, это на питончике с его динамической типизацией бац бац и выкатили… в рантайме упадет — норм, или голанг с его 'программист сам пусть следит за корректностью интерфейсов… перепутал объект с похожим интерфейсом… ну ниче… клиент потом в поддержку тикет напишет, нада лучче следить за кодом!'
а тут тебе и контроль при компиляции, и многословность (которую многие не любят, зато блин всё понятно что происходит) и ООП во все щели
UFO just landed and posted this here
Как будто что-то хорошее.

плохое это когда 70% проекта на процедурщине, а 25% на ООП и 5% на перловых скриптов которые вызываются странными путями
а то что язык весь ООП, это ни хорошо ни плохо, я последние лет 8 слышу что будущее за функциональщиной, и еще ни одного проекта с ней не видел… ruby, php, python, C#, java даже блин перл… полно, функциональщина… все глаза закатывают… вот если быыы… и пишут на питоне

Если же вы прыгаете с проекта на проект, с задачи (не в смысле таска в джире, а в смысле какой-то глобальной цели кода, который вы пишете) на задачу, то да, тогда это очень важное преимущество

очень важное, сейчас я работаю вроде как на одном проекте, но разветвленность кода такая… около 50 репозиториев, везде разные стили… там одно там другое… водном месте все понятно описано.
в другом одна строчка кода и 100500 неявных эвентов… велком ту дебаг, пойди всё отлови
UFO just landed and posted this here

Если начинать, то лучше с с#, всё настраивается в разы проще, вариантов как сбилдить 1-2 штуки в зависимости от версии, а не 100500 как на яве и очень много можно настроить через УИ тулзы и не надо прописывать зависимости ручками, с решарпером можно даже по началу не понимать как оно работает и всё за тебя сделается и добавиться куда нужно, а уж библиотеки пишут не как для тех кто хочет в исходники лезть, а как для тех кому не интересно как оно внутри работает.

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

План для начинающих: качаем IDE, например Eclipse; выполняем шаги по созданию проекта (они обычно расписаны на сайте IDE); создаём первый класс, в котором пишем свой Hello World; затем ctrl+s и ctrl+f11 - и оно запустилось.

Вполне коротко и быстро, разве нет?

так изкоробки только VS работает, все остальные IDE очень часто натыкаются на очень неявные костыли вроде «пропишите/установите интерпретатор», 'а собирать будете в gradle или maven?' (а я новичок, я хз что это за заклинания))
тотже эклипс мозг сожрет новичку… лучше уже jetbrains советовать, и то… как вспомню как я пытался Clion поднять чтобы проект с гитхаба пересобрать какойто...10 потов сошло… и это при том что я хоть и не умею в си, но представляю как оно там работает

Ну вы же писали про начинающих. А если с гита качаете проект, то значит уже претендуете на знания.

Сейчас на гите модно оставлять проекты на Maven, что означает сокрытие зависимостей. Точнее - перевод их из явных в неявные. Поэтому новичку кажется, что всё сложно, ведь он не видит зависимостей. Тогда вам нужно искать на гите инструкцию оп сборке. Хотя опять же, она там часто расчитана на тех, кто знает Maven, что опять заводит нас на очередной цикл непонимания. Да, это не совсем для новичков. Здесь можно посоветовать почитать что-нибудь о сборке под Maven, если у вас совсем нулевые знания.

А без mavena всё просто - подключаем библиотеки и радуемся жизни. Хотя если знаете maven, то опять же просто - жмёте build, и всё собираеся само.

Хотя если знаете maven, то опять же просто — жмёте build, и всё собираеся само.

ага, само, до тех пор пока вы не начинаете, опятьже, под какойнить bluetooth писать и оказывается что мавен не только jar подтягивает, но еще и dll и so, а иногда даже сишный код компилит… а если там чёто не получается… велком изучать мегабайтные логи на предмет ошибок

а если там чёто не получается…

А если получается?

Вообще, cross-language сборка тема не самая простая. Плюс работа с железом напрямую - тоже специфическая задача для Java, то есть её могут решать при помощи кучи костылей вместо упрощающих сборку решений. И в итоге получается, что вы возмущены работой конкретного человека, который собрал в одном месте множество разнородных составляющих. Но обвинение-то подано в адрес Java.

Я не вникал в работу с bluetooth на настольных системах, возможно там действительно нет приличной инфраструктурной обвязки. Тогда, если кто-то сумел сгородить костыльное решение, которое всё же позволяет вам работать с bluetooth, стоит сказать ему спасибо и за это, ведь иначе вообще бы ничего не было. И может быть так, что инфраструктура есть, но кто-то с опытом в основном в С, банально тянет туда знакомые ему библиотеки, а за ними необходимость писать С-код и сборки целого бегемота. Здесь просто надо разобраться. Но принципиально нелогично обвинять Java, если вы всё же ещё не успели разобраться.

Но принципиально нелогично обвинять Java, если вы всё же ещё не успели разобраться.

я не Java обвиняю, я говорю бравые хвалебные песни про Java зачастую умалчивают суровые реалии, которые не особо её выделяют из других языков

Ну вы же понимаете, что один сложный случай легко найдётся для любого языка. В целом же количество сложностей не очень большое. Хотя, чем более сложные проекты выполняются на языке, тем более сложной становится инфраструктура вокруг таких проектов, а потому требуются всё большие усилия по изучению. Но это же именно сложные проекты. А помимо них есть и простые. Давайте всё-таки начинать именно с простых, тогда и не будет суровых реалий. Ведь просто!

О, мне нравятся эти два варианта в Шарпе. Или получится, или не получится.

Года полтора тому пробовал шарп. Многое понравилось всё больше из последнего, что в dotnet core (не переврал название, надеюсь?). Работа с зависимостями - вообще восторг. Но вот по части методического обеспечения...

  • Если я находил примеры трёхлетней давности, то они практически всегда не работали

  • Наработанная кодовая база создавалась строго в рамках концепции «единственного правильного мнения». Доходило до смешного: мультиплатформенный UI фреймворк (не буду тыкать пальцем) имел треть тестов, работающих только под Windows.

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

Много в Шарпе хорошего, вкусного, полезного. Но вот это «думать совсем не обязательно» получается далеко не совсем безобидным. Фигни тоже хватает. Фигни вообще везде хватает.

Лично мне не зашёл из-за боли при попытке подружить с Линуксом. Можно, но только если следовать генеральной линии партии и не хотеть странного.

Доходило до смешного: мультиплатформенный UI фреймворк (не буду тыкать пальцем) имел треть тестов, работающих только под Windows.

А можно все-таки тыкнуть? Я знаю несколько, хотелось бы точно понимать о каком идет речь.

Мне кажется у вас это, как оно там, "ошибка выжившего" что-ли называется? Вы похоже не писали ничего серьезного ни на чем, кроме Java и поэтому считаете этот язык лучшим. Я тоже начинал с программируемых калькуляторов, и за свою карьеру много писал и на C/C++ и на Java по-крупному и на куче других языков "по-мелкому". И в принципе не очень согласен.

На мой взгляд, если говорить про совсем "новичков-новичков", то лучше питона, как современной замене бэйсика я думаю трудно найти:

  1. Это интерпетатор, достаточно написать пару строк и запустить и все работает. Можно даже прям в режиме интерпертатора что-то быстренько посмотреть иногда. И это на порядок сокращает "цикл разработки", что достаточно важно для новичков.

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

  2. Легко и просто найти и заинсталлить кучу расширений на все вкусы от графики до научной математики.

  3. И при всем при этом это вполне себе серьезный язык с ООП, в отличии от того-же бейскиа

На самом деле мне больше нравится ruby, в основном из-за синтаксиса, но к сожаленю python победил в этом соревновании...

Если же говорить не совсем про "новичков-новичков", а про "начинающих программистов", которые уже в принципе понимают что такое программирование и хотят так сказать "углубить" свои знания, то тут да, согласен Java может рассматриваться как один из вариантов, но не думаю что как единственный. И C++ и JavaScript и другие современные языки вполне себе с ней могут поконкурировать, хотя и в разных областях.

серьезный язык с ООП, в отличии от того-же бейскиа

в VB кстати (6.0), вполне себе ООП есть, может не такое изощренное как в яве. но всеже дает реализовать большую часть паттернов… (а современный VB, это фактически C# с другим синтаксисом)
p.s. а других бейсиков сейчас больше и нет в продакшене
На самом деле мне больше нравится ruby, в основном из-за синтаксиса

много слышал что там какойто особой синтаксис, мне довелось переписывать руби проекты на питоне и вообще разбираться, чёт немогу я согласится в наглядности этого кода
UFO just landed and posted this here

Я не знаю, о каких паттернах можно говорить в языке, где необъявленную переменную можно использовать как инициализированную по умолчанию.

Это вы сейчас про что? В python-е такого нет:

>>> print(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

PS: И в ruby тоже:

irb(main):001:0> print a
Traceback (most recent call last):
        2: from /usr/bin/irb:11:in `<main>'
        1: from (irb):1
NameError (undefined local variable or method `a' for main:Object)

Я не знаю, о каких паттернах можно говорить в языке, где необъявленную переменную можно использовать как инициализированную по умолчанию.

option explicit on — и всё
===
Sklott
А то что в питоне нет
constraction_total=10
construction_local=get_contraction() # 100500
print(constraction_total)
10
и никаких ошибок (упс)

Разгадка в том, что это переменные экземпляра модуля, поэтому к ним прристреливаются значения по умолчанию. В Java только поля класа и объекта получают значение по умолчанию.

много слышал что там какойто особой синтаксис, мне довелось переписывать руби проекты на питоне и вообще разбираться, чёт немогу я согласится в наглядности этого кода

Ну я думаю тут в основном дело вкуса. По сути python и ruby очень похожи по функционалу. Что мне больше нравится в ruby - это нормальные лямбды, а не вот это питоновское "функции - это полноценные объекты языка" или как у них там, они во многих языках полноценные объекты, но зачем мне нужно писать отдельную функцию, если мне надо использовать её только один раз в конкретном месте, я не понимаю.

Плюс в ruby еще есть mixin-ы, которых в питоне вроде нет, довольно удобный механизм иногда.

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

Mixin в python есть и достаточно активно изучаются на курсе для новичков, например в Яндекс практикум.

PEP8 или правильность оформления кода очень дисциплинируют, все программы читать легко! Главное же, что программа один раз пишется и десять читается и через много лет один и тот же код смайл.

Интерфейсы ввели раньше 6.0. Возможно в 4, но в 5-м точно были. Это ключевое, что даёт похожесть на ООП.

Чтобы настроить сборку простейшей программы на Java без предварительных знаний - умучаешся

Чуть выше уже показывал очень короткий набор шагов - https://habr.com/ru/post/684786/#comment_24666048

Вообще, похоже у комментирующих нет опыта работы с Java IDE, поэтому им кажется всё сложным. Но если IDE установлена и вы хоть немного умеете ею пользоваться - всё остальное тривиально. Проще, чем на С++.

Проще, чем на С++.

На C++ нет "стандартной" системы сборки. А из тех что поддерживают C++ есть IMHO и получше, чем gradle или maven...

Где-то в начале 90-х появился Borland C, в котором основные идеи сборки в IDE были реализованы очень практично и наглядно. То есть сборка средствами IDE - старая и очень эффективная история.

Если не ошибаюсь, сейчас сборкой "средствами IDE", кроме Visual Studio никто не занимается. Все остальные используют сторонние инструменты.

И для этого есть веские причины: когда у тебя pet проект, в котором можно настроить сборку парой раз ткнув мышкой - это одно. А вот когда у тебя собираются сотни тысяч файлов, когда процедуры сборки правится десятками людей, когда нужно сохранять разные версии билдовой процедуры на разных бранчах и потом их мержить, то все UI и проприетарные форматы идут в сад и использются "стандартные" решения.

Нет смысл спорить с потребностью в системах сборки. Но всё началось с того, что вы написали про сборку простейшей программы. Простейшие (и не только) программы самым простым образом собираются именно средствами IDE.

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

Тоже не понимаю, в чем проблема с NetBeans IDE

  1. Установка NetBeans полностью автоматизирована, ничего прописывать и корректировать не надо, всё по умолчанию, т.е. несколько кнопок "ОК"

  2. Запуск IDE и кнопка "Создать проект" или на базе простейшего примера

  3. Кнопка "Пуск" и всё

Не надо в 2022 использовать NetBeans. Стоит сразу привыкать к IDEA, она вроде как промышленный стандарт уже стала, тем более, что лучшее из NetBeans там есть. А уж что касается поддержки разных фреймворков...

И да, в IDEA можно собрать проект средствами IDE и ручным подключением библиотек, но зачем?

Ставил IDEA, может неправильно ставил, но это такие тормоза

к сожалению нетбинс практически помер и привыкать придется к идее, просто потому что это уже фактически отраслевой стандарт

Согласен, лучше с питона... или даже хаскеля!

По мне так главное, это на каких задачах учиться. Сейчас многие вкатываются не в язык, а в фреймворк над языком. Например, есть куча биоинформатиков или дата-сатанистов, которые уверены, что программирование - это найти и вызвать либу с функцией .analyzeMyData(data). И ни шага в сторону. Есть и "джависты", которые умеют только аннотации в спринг-буте расставлять. Вот это все лажа. Если заходить серьезно, то нужно начинать с типов, структур, операторов, циклов. Несмотря на все потуги но-код движения, эти понятия никуда со сцены не уходят. По мне лучше это делать на ЯВУ со строгой типизацией, то есть и джава и шарп и плюсы подойдут, но это скорее моя вкусовщина.

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

а в чем собственно проблема? это вполне вписывается в логику языка построенного на принципах ООП

Это уж лучше выглядит питона с его «if __name__ == '__main__':» — у меня до сих пор глаз спотыкается об этот костыль

Для "Hello world!" не обязательно уточнять точку входа, и даже создавать функцию (не говоря уже про класс с методом). :)

тоесть из ООП языка сделать процедурный, так?

Синьера от джуна отличает умение выбрать нужное количество слоев-абстракций, золотую средину межде хардкодом и софткодом, количеством зацеплений-зависимостей и т.п. исходя из задачь бизнеса. Задача бизнеса вывести "Hello world", используем паттерн скрипт, ни каких процедур. :) Хороший язык это позволяет.

тоесть из ООП языка сделать процедурный, так?

Использовать процедурный подход мультипарадигменного языка. Питон он же как огр лук, - многослойный, - и ООП, и процедурщина это просто разные слои )

и зачем собственно? чтобы учеников текст не смущал лишний?
ЯП это инструмент и есть правила как инструментом пользоваться, если правила не нравятся — бери другой инструмент, всё просто
Ява создавалась во времена когда всякими упрощательствами (злобный взор в сторону неявных имплементаций интерфейсов у голанга и 'простых и задорных горутин' которые работают на магии, а в яве чёто все морочатся и целые книги пишут как многопоточность синхронизировать) еще не упарывались, а надеялись что человек если пишет — он понимает что делает… а если не понимает то язык его своим дизайном заставляет писать так чтобы он понимал

а в чем собственно проблема? это вполне вписывается в логику языка построенного на принципах ООП

Именно. Это концепты ООП, от которого начинающих стоит держать подальше. До ООП им еще нужно пройти долгий путь, - понять что такой вообще поток выполнения, переменные, функции, циклы, базовые алгоритмы и прочее такое всякое. ООП это уже про организацию и архитектуру кода.

И главное - зачем всё это нужно. Желательно, с примерами из собственной жизни.

Стань Джедаем Java и получай three hundred thousands bucks (300 000$) to release your deep dark fantasies.

Да не нужен этот костыль для hello world, просто берете и пишете всю программу прямо в файле. Трюк с "if __name__" вам потребуется только если вы этот файл и импортировать, и как отдельную программу запускать захотите. А это уже намного более продвинутый уровень.

Слабый довод. Метод мейн - это такая условность, через которую при обучении можно один раз перешагнуть и спокойно шпарить дальше чистую процедурщину без всякой мысли про ООП. Если этот момент реально мешает изучить язык, то у меня вопросы совсем не к языку.

И в целом не надо путать сложность чего-то и незнакомость с чем-то. В первый раз все тяжело.

тогда уж Kotlin - Java нормального человека. )

ну да, типа того.

причем уже лет 15 можно в той же роли использовать groovy. И все те же самые преимущества будут в наличии — язык простой и удобный (синтаксис лучше питона, более простой и логичный во многих местах), экосистема JVM в наличии, библиотек куча, интероперабельность на уровне… и по сути, вся разница с питоном — в том что экосистемы разные, развивающиеся в разные стороны.

Понимаю, что это дело вкуса, привычки и тараканов в голове, но Питон в моем личном рейтинге языков с которыми я хоть немного знаком занимает, пожалуй, последнюю строчку. С Груви почти незнаком, но использование его в gradle файлах для сборки под андроид, если честно, не показалось мне интуитивно понятным, хотя то не вина языка, кончено. ))

Да в общем-то я даже не совсем про питон говорил — а скорее про то, что если уж кому-то хочется учиться в экосистеме Java, то котлин (11 лет), и груви (уже 19) — намного более удобные языки для того, чтобы начать разрабатывать, оставаясь при этом в рамках экосистемы. Выбор между ними — ну уже да, в какой-то мере дело вкуса. Ну то есть, если бы мне пришлось на сегодня учить начинающего — я бы однозначно не выбрал бы Java именно как язык, при том что платформа jvm — мой основной инструмент. Я уж лучше со скалы начну учить — аккуратно обойдя ненужные новичку сложности.

При выборе языка немаловажным фактором является текущий и перспективный спрос на него у работодателей. Беглый обзор вакансий показывает, что груви является скорее "вспомогательным" языком, чем основной боевой единицей для разработчика. Скала, да, возможно неплохой выбор в этом плане, но с этим языком я не сталкивался совсем, судить не могу, знаю, что Котлин проще при этом достаточно универсален и действительно хорош,а главное есть некоторые надежды на то, что он пусть не сразу, но заборет хайповую связку Флаттер+Дарт на мобилках, а может и на десктопах приживется. Зоопарк языков ставит в тупик начинающих разработчиков, и, вероятно, немного раздражает опытных. Да, мантры про то, что нет лучшего языка, что все зависит от задач верны, но вот, ИМХО, задач (ниш) не так уж много, и хорошо бы уже этот естественный отбор языков застать на завершающей стадии. ))

Если смотреть с позиции новичка, то в статье проблема - новичок твёрдо уверен что сейчас Java правильно называется Kotlin, а автор отмалчивается.

Сам же вопрос с чего кому начинать - запретительно сложный. С Java Script и писать на нём вообще всё через Node.js, Electron и Capacitor? С Dart и писать почти всё на Flutter? Методично учить Neovim, Lua, C++ чтобы ей в полной мере воспользоваться, SDL/Skia... и до выхода Carbon свободен? Решить что вне Эппл нет жизни, купить iPad и учить Swift? Решить, что вне Интернет нет жизни и учить Rust ради WebAssembly и PWA?

Я не знаю как с этим быть и не думаю что можно, руководствуясь принципом "не навреди", что-то рекомендовать. Вместо рекомендаций что-то типа "Какие лакуны в образовании можно закрыть занявшись Java"...

новичок твёрдо уверен что сейчас Java правильно называется Kotlin, а автор отмалчивается

В тексте есть про Kotlin, только название там правильное, изначальное, то есть по русски (поищите поиском). Kotlin в основном под Android. И не все новички вообще знают о существовании Kotlin-а.

Про остров - это замечательно интересно, но по теме, почему именно Java, формально не написано ничего, а неформально - не надо отказываться от Java потому что за нас от неё уже отказался Гугол. Как-то не очень убедительно, с первого чтения даже как аргумент не заметил.

Кстати, утверждение что Котлин полностью подконтролен Гуглу означает, что JetBrains тоже полностью подконтрольна Гуглу. Это точно так?

JetBrains тоже полностью подконтрольна Гуглу

JetBrains - подрядчик. Подконтрольность, соответственно, на уровне подрядчика. А язык предназначен для замены подконтрольной Oracle Java на Android. Поэтому в договоре с гуглом JetBrains, разумеется, подписались под многими пунктами, предоставляющими гуглам возможность максимального контроля.

Отказ же гугл от Java отнюдь не смертелен, потому что основная денежная ниша Java - это так называемый backend, где у гуглов мало что получается. Хотя и туда они пробуют залезть со своим Go. Но, как видите, даже сами гуглы имеют альтернативу Котлину. Так что кто тут от чего отказался - пока что весьма зыбкое поле для размышлений.

Поэтому в договоре с гуглом JetBrains, разумеется, подписались под многими пунктами, предоставляющими гуглам возможность максимального контроля.

Под какими например? JetBrains, конечно, кооперирует с гуглом (так как и другими компаниями, типа меты), но ни о каком максимальном контроле речи не идет.

Неважно с чего начинать. Главное, думаю, понять саму суть работы алгоритмов, принципов работы кода и как всё это работает с железом. А насчёт языков, конечно у каждого свои особенности и уровень вхождения, но если тебе 25+, то начни вот прям с любого ЯП. Дальше уже поняв основы, можешь быстро переориентироваться под любое понравившееся направление.

PS: Если хочешь сразу видеть результат работы на экране: HTML/CSS + JS вот базовый набор.

Если хочешь сразу видеть результат работы на экране

Тогда нужно no-code решение.

Такими решениями придем к тому, что будем лишь писать приказы к ИИ, а ИИ сам уже напишет код, соберет проект, и развернёт его на сервере.

Ха! Сразу результат на экране…
В институте я изучал программирование на ЕСках. Где команда PRINT — это реально печать на бумаге на барабанном принтере. Без никаких там экранов. А результат работы программы можно было увидеть завтра, потому что лаборантки только вечером разрывали на кусочки результаты печати всех программ за день.
Так что для своевременной сдачи лабораторок надо было писать программы сразу без ошибок. Чтобы с одного прогона правильно отработало. Потому что следущий раз машинное время перепадёт только через неделю.

Если говорить про JVM-мир, то в наше время логичнее начинать сразу с Котлина.

И замкнуться в мире гугл и андроид.

а как же Kotlin Multiplatform, Compose Multiplatform ? ИМХО, неплохие перспективы на будущее.

Backend очень инертен, там этого добра не будет ещё весьма длительное время. А возможно и вообще никогда не будет, ну кроме малоизвестных проектов некоторых энтузиастов.

Хотя борьба гугла за котлин может в итоге и пододвинет Java, но пока что это, в лучшем случае, перспектива через лет 5-10. А в худшем - никогда.

https://hh.ru/search/vacancy?text=kotlin+Backend+developer

Соглашусь, инертность мышления - очень сильный фактор, но количество людей оценивших плюсы kotlin будет расти, и поводов к обратной тенденции я пока не вижу. По ссылке чень немало упоминаний kotlin, пусть чаще в связке с java, и тенденция положительная. (я поглядываю иногда).

Что именно в дизайне котлина "замыкает" его на чем-то?

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

Я убежден, что проф программист обязан пощупать память руками, даже если потом в реальной практике он будет работать с высоким уровнем абстракции. Все эти ручные выделения и освобождения памяти, адреса и указатели, ошибки доступа, ручная работа со строками и прочее — формируют мышление и полезное понимание, что происходит под капотом. И что синтаксический сахар, от которого у всех уже слиплось в одном месте, не бесплатен.
Ассемблер желательно, но всё же не обязательно. Ручное управление памятью обязательно.

Я бы сказал по другому - грамотный программист просто должен понимать, что происходит внутри программы. Только способ достижения такого понимания может быть разным. На мой взгляд, на Java понимание наступит не сильно позже, чем в случае с С, если речь идёт о чём-то, что выше уровня общения с железом (а такого софта - большая часть). Сама же базовая концепция линейки байт, реализуется почти во всех языках и "щупать" эти байты, соответственно, можно не вспоминая о более близких к машине языках.

В целом всё зависит от способа обучения. Если способ предполагает наличие опытного разработчика, хотя бы неявно, в виде автора книги, то и понимание никуда не денется. А если прыгать по случайным проектам сразу, освоив только Hello World, тогда и на С понимание может очень долго не наступить.

Понимание к сожалению наступит сильно позже. Потому что изучать в самом начале концепцию машинной памяти и как на неё отображаются структуры данных - это немного отличается от расстановки аннотаций и создания репозиториев. Причём второй путь зачастую быстрее приводит к желаемому результату, что в создании фич, что в прохождении собеседований. Но вот когда оно начинает упираться в производительность или объём памяти... тогда C-like знания становятся нужны. Но это уже как бы и не уровень джуна.

Да, большинство курсов ориентировано на скорость и игнорирует глубины. Это плохо.

Для начального обучения с полного нуля надо брать Python.

Не обязательно. Kotlin, C# не менее сложные и такие же лаконичные, но со статической типизацией.

Для обучения с полного нуля статическая типизация — не плюс, а минус.
Это там, где изучают, что такое вообще переменная, условие, цикл, функция…

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

Начните с трёхтомника Кнута. Это путь настоящего самурая.

через всю статью красной нитью прошито "ох, begin не нужно писать ! end не нужно писать ! Ах, ох !"

Автору бы ArnoldC попробовать. Там каждую цитату знать надо!

Всё так. Да и научиться программировать на джаве очень легко. Всё что нужно, это научиться писать код так, чтобы не возникало ошибки null pointer exception.

Вот как этого добиться, это другой вопрос. Потребуется всего лишь удерживать в уме 25+ паттернов проектирования и использовать их при написании кода. Поначалу кажется, что это невозможно, ибо все эти паттерны противоречат друг другу, но через каких-то 25+ лет опыта вы научитесь так умело ими жонглировать, что они даже не будут мешать другу другу, и вам наконец удастся избежать null pointer exception в рантайме (но это не точно).

Lombok наше всё :) Мы вот попытались имитировать в проекте null-safe концепцию из Kotlin путём совместного использования @NonNull, @Nullable и Optional<>. Вместе со статическим анализом и хинтами IDEA получается очень даже ничего. NPE становится рабочим исключением и обычно ловится тестами

Похоже, многие комментирующие, и в том числе вы, почему-то считают, что Java, это что-то сложное. Но как видно из вашего примера, проблема не в Java, а в необходимости изучать достаточно большие объёмы необходимой информации. И эта информация потребуется для создания серьёзной программы на любом языке.

Поэтому ваш сарказм про, по сути, "сложность" самых базовых вещей, скорее характеризует вас, но никак не Java.

Ну и к чему эти переходы на личности?

Вы статью вроде как для начинающих написали? Что это за такие начинающие в вашем понимании, если навык грамотного применения различных ооп-шаблонов проектирования это базовые вещи!?

В моем представлении начинающие рисуют разноцветные концентрические окружности циклами и анимацию зеленых фигур Лиссажу на черном фоне, имитируя осциллограф.

Во первых, вы начали и закончили c NullPointerException. Это действительно - самые базовые вещи, то есть работа с переменными и понимание, что это такое.

По шаблонам - они разные. Есть безумно примитивные. Есть посложнее. И есть способ обучения, когда в голову льют курс типа "делай только так, потому что это шаблон проектирования". Последнее - плохо. Вас не учат, а морочат мозг. И разумеется, после таких курсов люди ждут магии от шаблонов и считают их верхом сложности. Но это всего лишь шаблоны. Как женщины из теста звёздочки вырезают, тыкая шаблоном - вот примерно такая же суть, просто для ускорения и упрощения решения стандартных задач.

Переход на личности, если это вообще можно так назвать, был попыткой призвать вас к хоть какой-то ответственности за свои очень вольно разбрасываемые слова. Хотя да, сегодня в моде максимальная безответственность, здесь я "попал". Или это тоже переход на личности и я попал дважды?

Имхо: Python (чтобы заинтересовать) -> C (пощупать железо) -> Java (пощупать ООП) -> Haskell (пощупать ФП).

Изначально это была упрощённая Java, урезанная ради лёгкости применения, в первую очередь, в браузерах.

YAmROOEhxc0

Попался на название Javascript. Его назвали не тупо из-за копирастии из Java, а тупо из-за рекламы. Ибо аббревиатура ECMA не была понятна рядовому юзеру.

Почему после 25+ лет в Java я бы рекомендовал начинать с Java

Изначально это была упрощённая Java, урезанная ради лёгкости применения, в первую очередь, в браузерах.

Писать такое в статье для новичков стыд и позор, прежде чем кому-то что-то советовать стоило бы ознакомиться с упоминаемыми вещами.

Можно почитать историю JavaScript в википедии. Например, там есть такое:

Netscape management soon decided that the best option was for Eich to
devise a new language, with syntax similar to Java and less like Scheme
or other extant scripting languages.[5][6] Although the new language and its interpreter implementation were called LiveScript when first shipped as part of a Navigator beta in September 1995, the name was changed to JavaScript for the official release in December

В вики пишут, что вообще хотели чистую Java, но всё-таки вопрос контроля над разработкой был важнее, ну и решили сделать "with syntax similar to Java", дабы привлечь максимум аудитории, подогретой фирмой Sun с её уже популярной Java.

Впринципе по статье уже понятно, что у вас критерий схожести - визуально похоже (в статье про синтаксис вспоминают постоянно), рекомендую при таком подходе наждачку и туалетную бумагу тоже вместе классифицировать - в названии и там и там "бумага", и та и та в руллонах...

Если бы вы собственную ссылку на вики прочитали внимательно, то как минимум нашли бы это:

Although Java and JavaScript are similar in name, syntax, and respective standard libraries, the two languages are distinct and differ greatly in design.

Еще есть вот это:

It has dynamic typing, prototype-based object-orientation,...

Из этого можно сделать вывод что либо вы про JavaScript особо ничего не знаете, либо про Java (либо и про то и про другое).

Вы конечно не сказали после 25+ лет в какой профессии вы рекоммендации раздаете, но матчасть явно стоит подучить.

javascript лучше для начинающего

начинающему лучше если всё будет в разы проще

чтобы начать например с 12ти лет

и можно программировать микроконтроллеры - это шикарные перспективы

и далее можно при желании легко перейти на java

Я в программировании чуть больше тридцати лет и все больше убеждаюсь, глядя на молодых программистов и их "код", что начинать надо с языков специально созданных для изучения алгоритмов, в первую очередь, это Паскаль. Потом двигаться в сторону Си, можно и одновременно, для изучения хранения структур данных в памяти и вообще работы с памятью.
А дальше уже брать ООП язык, и тут конечно рулит Java.

в первую очередь, это Паскаль

ну зачем блин… зачем? там полно подходов которые сейчас уже не применяются
Это всёравно что учится ездить на паровом авто чтобы понять как ездить на бензиновом автомобиле.

Паскаль, при всем уважении к делфи, уже фактически устаревший язык
а учить циклы, условия и прочее, можно и на любом более современном языке

Еще раз, Паскаль единственный нормальный вводный язык для понимания алгоритмов. Для возраста 10-14 лет вообще самое то. Писать на нем конечно нечего, но развивать мышление очень даже. Он и создан был именно как учебный язык программирования. Осваивается за день, структурный, и очень-очень простой.
Для обучения с нуля нельзя использовать "сложные" языки, у которых много особенностей, как тот же Си, Си++, Java, Python и прочее из топа популярных. По той простой причине, что вместо изучения алгоритмов начинается изучение собственно языка, что отвлекает внимание от алгоритмов. А если изучать алгоритмы на тех же сях или жаве, не особо упирая на специфику языка, можно приобрести ряд нехороших привычек, которые в серьезных проектах будут вредны.

Не знал, что Java программисты находятся в настолько удручающем положении, что выдают такое вот чтиво...

По мне так всё равно как учить программирование. Я начинал в школе с Basic, доступ к компу был раз в неделю часа по три-четыре. Программировать фактически начинал на бумаге. У меня были тетрадки, исписанные строками кода. После школы самостоятельно изучал C++. Месяца через 3-4 смог уже сам научился ставить себе задачи и самостоятельно достигать результат. Позже самостоятельно подружился с Java.

Я считаю, что нет «СамогоЛучшегоСпособа» начать учиться программированию. Если желание сильно, то научишься. Если желания нет - зачем тогда учиться? Любой способ как начальный - годится, т.к. в зависимости от контекста может потребовать любой опыт.

Программирование - это про ясность цели, а не про язык. Может вы путаете с кодированием?

Sign up to leave a comment.

Articles