вы правда хотите получить карьерный совет от незнакомых людей в чате?

а от кого еще?)

хотите, мы еще по фотке скажем, какой гриб ядовитый, а какой - нет

Если программа не Hello World одним файлом, то не можешь package com.habr; public class App { public static void main( String[] args ) { System.out.println("Hello World"); } } Пакет обязан указывать, где хранится твой класс. Надеюсь мы не обсуждаем написание программ на этом языке, как делалось при создании в версии 1.1

чо поулчается, на жабу переходить? просто в моей стране почти все вакансии - жаба, на гошке пару синбйоров...

в плане обучения, если нужно именно набить руку написания кода, понять как вообще программа работает с т.з. алгоритмики, ну и чисто пофаниться, рекомендую пощупать https://processing.org/ Там два варианта - на базе джавы и на базе js. Никаких вам классов, пакетов и ООП вначале. Чисто рисование.

☠️☠️☠️

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

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

у меня про js особое мнение. но я промолчу :-) в качестве первого языка, для набивки руки на базовых императивных концепциям (структурное программирование и всё что с ним связано -- операторы ветвления, циклы, массивы, функции/процедуры, ПЕРЕМЕННЫЕ, хоть какие-то типы) можно вообще брать что угодно. Можно и условно мёртвые языки брать, хоть тот же паскаль. Лишь бы язык на этом уровне не был совсем уж кривым. И ещё важно, чтобы процесс доставлял фан и давал непосредственный (желательно визуальный) фидбек. Когда-то для этого использовали турбопаскаль (там отличная графическая библиотека, не требующая от начинающего вообще ничего) сейчас вот процессинг хорош. Есть и другие варианты конечно.

процессинг, увы, сложно будет потом применить. А js спокойно перерастает в TS, и это готовый очень ликвидный скилл

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

хм. джава вроде довольно вольно с типами обращается. это не Ocaml не Haskell и не Ada :-)

😆 новичек с одних массивов там поплывет скорее всего

😆 новичек с одних массивов там поплывет скорее всего

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

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

поэтому в задачах на матрицы уточняют условие, а если нужна скорость, то даже для матриц используют одномерный массив [n * n]

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

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

а json это что :)

ну ок. если для вас json никак не связан с массивами

ой всё. вот у кого каша в глове дак это у вас 😆

это формат данных никак прямо не связан с массивами. Его можно представить в разных форматах и структурах данных, в том числе и массиве, но если мы берем Java, то массивом можно представить определенную часть json'а, заключенную в квадратные скобки, и да и вообще причем тут Java как таковая не очень понятно. А еще смешались в кучу бэк на php и Dart с Flutter

парсить json мы не умеем

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

А есть хоть один с доказательствами наличия этой самой проблемы? Не нытье, что не как у нас в петонах,а посущественней что-то.

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

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

Да, я понял, что я спросил. Хватить бузить, не на кухне >у Го проблема с >А есть хоть один с доказательствами наличия этой самой проблемы

не согласен. то есть может у разработчиков есть такая психологическая проблема, что хочется как-то самоидентифицироваться, но у языка то точно нет проблемы. Обычный прагматичный мультипарадигменный язык. Как та же Джава, или С++, или Паскаль (начиная с турбо-паскаля, точнее с обоих Object Pascal'eй), или даже Оберон.

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

Это мудаковая быдлячая форма ответа. И опять она же.

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

собственно однопарадигменных ЯП вообще, мягко говоря, мало среди тех, что используют на практике. Например OCaml -- мультипарадигменный. Scala -- тоже. Не говоря уже о всем остальном вроде js/python/f#/c#/etc.

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

почему хрень. Сишникам как раз очень легко перейти на Го и это действительно замечено

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

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

так это и в целом стало не выгодно, двигаться куда то только в одну сторону. С распространением FaaS, строить в стиле ООП абстракцию над абстракцией, трата ресурсов в никуда.

очень холиворно :-) у языков есть много фич и направлений. язык обычно состоит из нескольких подъязыков. например есть язык выражений (не регулярных), язык деклаций, язык модульный (про модули, экспорты, импорты и пакеты) и так далее. потом, отдельно, есть типизация (сюда иногда залетает и кусок ООП уже и ФП). Так вот в Го есть и язык модулей, и система типов поддерживающая базу для ООП и ФП (функции как отдельный тип и first class citizen), плюс язык для коммуникации горутин. У Си нет языка модулей, зато есть язык препроцессора, ООП явно не поддержано. ФП -- поддержано частично. Чего в Го не хватает для нормального ФП -- нехватает наличия отсутствия изменяемого состояния и, в идеале, в языке не должно быть statements, должны быть только expressions. То есть чтобы из языка сделать ФП язык, в него не столько добавлять что-то нужно, сколько удалять нужно.

А нужно ли делать из него функциональный язык?

не получится из него сделать функциональный язык вообще никак. слишком много statements слишком мало expressions.

Так и не нужно как по мне

ага. а кто-то хочет?

Вверху считают что у го проблемы с самоопределением) Я так понимаю самоопределится, значит примкнуть к одному из лагерей

когда был маленьким, тоже считал, что class в C++ это про ООП :-)