Go как язык для обучения программированию

    tl;dr: Go достаточно многословный и строгий язык программирования с очень предсказуемой и стремительной кривой обучения, что делает его крайне удачной технологией для обучения программированию новоприбывших!

    Я только приехал из штатов, после Google Code-In 2014 Grand Prize Trip, отдохнувший и веселый. Какое-то время думал написать отчет о том, чем призеры там занимались, как нас приняли в Mountain View и обо всем этом, но в какой-то момент понял, что все это совершенно бесполезно. Совсем недавно я по воле случая должен был помочь своему товарищу с домашкой по информатике (там было что-то вроде selection sort). Реализация требовалась на паскале, а я паскаль знаю очень плохо, как впрочем и другие неактуальные, по большей мере, языки программирования, вроде Ada.

    В меня ударила молния и укусил гофер, после чего мое тело мутировало в какую-то кунг фу Go хренотень. Иными словами, я задумался о возможном потенциале моего любимчика среди новых технологий, Go, в качестве языка для обучения программированию новоприбывших (читай: школьников). Мне кажется, у Go есть все, что в принципе может быть нужно подобной программе и даже чуточку больше (например, в школе могли бы затрагивать тему параллельного, ни в коем случае не concurrent, программирования, которую не затрагивают, просто потому что FPS вообще не умеет гонять два куска кода одновременно). Под катом, собственно, мои мысли на этот счет. Кстати, пользуясь случаем, хочу передать привет divan0! Большое спасибо за твою просветительскую деятельность в тематическом хабе: Go действительно нуждается в огласке, ведь много людей до сих пор считают, что это какая-то страшная поделка уровня Plan9 из 80-х и к тому же, без обобщенного программирования (в каждой шутке есть доля шутки), а ты рассказываешь людям очень правильные вещи на понятном для них языке! Никакого дисклаймера не будет, но я настоятельно не рекоммендую воспринимать содержимое статьи абсолютно серьезно, ведь я человек, у которого есть целых два гофера: синий и розовый!


    Довод №1. Многословность и строгость


    Меня безумно раздражает слово «многословность», но если я уже взялся писать статью, то надо переводить verbose на русский. Почему многословность это хорошо? Многословность упрощает понимание кода на экране, так как при недостаточной многословности у читающего могут возникать вопросы уровня «А что эта штука ваще делает?». Можно долго упираться в крайности типа Haskell vs Cobol, но суть и так понятна. Почему многословность это плохо? Адепты религии DRY неоднократно напоминают мне о том, что в Go нет генериков (обобщенное программирование). Вместо генериков предлагают бутсрапинг или кодогенерацию. Тем не менее, архитектура языка программирования это всегда определенные сделки: ручное управление памятью против сборщика мусора, генерики против бутстрапинга, динамическая типизация против статической, это можно продолжать вечно.

    Что касается строгости, то тут Go меня очень радует. Компилятор никогда не идет на уступки с программистом и любая, казалось бы, мелочь, которая в компиляторах других ЯП выльется в неприметный warning, тут — будет ошибкой компиляции. Не играешь по правилам спецификации языка — не получишь бинарник, все просто. Компилятор до того придирчив, что валит компиляцию при виде неиспользованного модуля. По-моему, это просто обосраться, как волшебно, особенно если тебе 15 лет, ты только пришел в программирование и хочешь сделать все «по-быстрее». Я прямо сплю и вижу школьника за компьютером, который пытается скомпилировать программу, но терпит фиаско; затем, проговаривая в голове все маты, которые он только знает, возвращается в редактор, чтобы убрать modulename из include-списка. Жестко? Еще бы! Но знаете, такая жесткость, она воспитывает!

    Довод №2. Потрясная кривая обучения


    В архитектуру Go заложена простота. Пайк где-то говорил, я уже не помню где, что они действительно вырезали все, что можно было вырезать. Ради этой простоты, в Go нету трех типов циклов (C-way), а всего один (и это без потери выразительности!), в Go нету продвинутой системы типов (но есть волшебные интерфейсы!) и в таком духе. Я уверен и даже готов поставить на это свои тапки (дорогие тапки, к слову, заграничные), что обычный такой школьник не станет читать спецификацию языка, так что не буду упоминать о ней. Так или иначе, язык, ввиду своей простоты и умеренной многословности, обеспечивает стремительную и предсказуемую кривую обучения. Но хотя бы факт того, что память-то managed, уже снимает кучу проблем уровня «так это что получается, вот эта функция у меня протекает? не может быть!».

    О том, что опытный программист полностью осваивает Go, со всеми его подводными камнями, за несколько выходных, уже неоднократно говорили, но это в контексте статьи не имеет смысла. Я не занимался обучением детишек на Go, так что суровых чисел у меня нет, но я предлагаю пораскинуть извилинами. Какие три вещи забирают, на этапе обучения, больше всего времени? Чемпион, это, очевидно, ручное управление памятью и мистер «я умудрился посадить сборщик мусора на половину рантайма» в языках с managed памятью. Второе место, безусловно, занимает тематика ссылки-указатели в разных контекстах (косяки уровня «присвоил не по ссылке, а по значению»). Замыкает тройку мистер ООП, а точнее проблемы, которые возникают в реализациях ООП: «так он приватный или нет?», «деструктор мне таки делать виртуальным?», «а как наследовать два класса одновременно???» и подобные.

    В Go память управляется автоматически, а значит, накосячить тут сложно. Существует правило, которое позволяет четко определить (в большинстве случаев), передавать переменную по значению или по ссылке: «Если ты собираешься передать право владения над переменной, то надо передавать по ссылке, иначе — по значению. Стандартный набор проблем с ООП не появится, потому что Go прибегнул к очень красивым решениям касательно объектно-ориентированного программирования. А именно, Pike & Co. выпилили классы, всякое „ambiguous“ наследование и прочую инкапсуляцию, предлагая структуры, интерфесы, embedding. Проблему инкапсуляции решили до безобразия интересно: все поля структуры, которые начинаются с символа верхнего регистра идут наружу, а все остальное остается внутри.

    Я обрисовал картину, а выводы уже делать вам. Мне кажется, что все очень даже волшебно.

    Довод №3. Многопоточное программирование


    Я считаю, что детям уже в школе очень важно давать навыки работы с многопоточными приложениями. Знаете ли, мало прикольного в том, что студент, опыт которого так или иначе сводится к проектам уровня laba3, попадает в реальный проект, где одновременно выполняется много кода, все ресурсы надо закрывать на мьютексы, к тому же это все надо еще покрыть тестами… Компьютеры уже давно могут параллельно выполнять несколько задач (parallel != concurrent), за счет архитектуры процессоров и этим нужно пользоваться. Я считаю, что рядом с некоторыми классическими реализациями некоторых алгоритмов надо также давать параллельные их реализации. Того же selection sort, например.

    Go избавился от злых и страшных потоков, на замену которым пришли горутины. Я думаю, что работать с корутинами (=задачами), на уровне понимания, куда легче, чем с потоками. Канал, казалось бы, просто очередь, но плюхи на уровне синтаксиса делают работу с ним интуитивно понятнее и куда очевиднее. Как бы долго я не нахваливал корутины, каналы и select, так или иначе мы все равно упираемся в мьютексы. Тем не менее, я думаю, что это все равно лучше, чем то, что мы видим сегодня в других языках, особенно говоря в контексте обучения.

    Немного о Python


    Какое-то время пайтон считается очень хорошим языком для обучения. Аргументы: интерпретируется, типизация, curly brackets — gotta go! Я не хочу лишний раз поднимать срач, но могу сказать, что по части кривой обучения, Python очень подлая штука. А еще у меня есть мнение, что программист начинает ценить достоинства и уважать недостатки динамической типизации только после определенного времени проведенного со статической типизацией. Я не считаю, что новоприбывшему стоит велосипедить-куралесить с динамическими типами, пока он толком не поймет, что такое тип вообще. К сожалению, для талантливого программиста Алеши из 8А это не так очевидно.

    Конец


    Ну, это все. Спасибо всем, кто осилил этот дамп моего сознания, надеюсь, что кому-то это было интересно. Прикольно будет, если какой-то инициативный чувак с преподавательскими навыками прочтет и в последствии родит рабочую образовательную систему! Нет, это правда будет отлично! Ах да, не стесняйтесь задавать у меня какие-либо вопросы: в комментариях и даже в личке!
    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 96
    • +4
      В принципе, аргументация понятная, но ответ на вопрос, хорош ли язык для обучения программированию можно дать только на основе реального опыта использования его в таком качестве. Потому что не исключено, что избавившись от одних подводных камней, создатели языка набросали других.
      • +1
        Я вот Go не знаю, но например на C++ можно точно также писать на небольшом его подмножестве, даже включив опции комилятора «считать предупреждения за ошибки», все будет тоже также валится. А можно и на C++/CLI перейти для надежности.

        Так чем таки Go хорошь?
        • +3
          Пока я читал ваш комментарий, у меня случился Error: Segmentation fault
          • +1
            А если серьезно, то я сам начинал обучение с C и C++.
            Какой довод вам не ясен из перечисленных?
            • –1
              Все доводы слишком туманные и неочевидные, хорошо если бы конкретные примеры это показывали. Насчет простоты:

              C++ сегодня прост, как и бейсик в 80ые

              #include «basic.hpp»

              int main()
              {
              _10: LET X = 1;
              _20: LET SUM = 0;
              _30: LET DEPTH = 1;
              _40: INPUT «Enter a positive number: », X;
              _50: IF X > 0 THEN GOTO _130;
              _60: PRINT «By positive, I mean greater than zero. You entered », X, " which isn't";
              _70: GOTO _40;
              _80: SUM = SUM + X;
              _90: X = X — 1;
              _100: IF X > 0 THEN GOSUB _80;
              _110: DEPTH = DEPTH * 2;
              _120: RETURN;
              _130: GOSUB _80;
              _140: PRINT «SUM=», SUM, " DEPTH=", DEPTH;
              }

              https://github.com/rollbear/basicpp
        • +5
          Как бы я ни хотел найти лучшую замену Питону для обучения, но Go для этого не создавался. Насколько я помню, львиную долю времени мы, будучи школьниками и студентами, писали алгоритмы и структуры данных. Без обобщений такие вещи делать некрасиво, а пользоваться втсроенными в язык — значит ничему не научиться.

          И раз уж мы затронули эту злободневную тему, не расскажете ли преимущества «бутсрапинга или кодогенерации» перед нормальными обобщениями?
          • +4
            Чтобы было что обобщать, надо для начала научиться делать частности. Генерики формируют дополнительный слой абстракции, который на начальном этапе не нужен…
            • 0
              Я по большей частью согласен, НО «дополнительный слой абстракции» — это скорее про «бутсрапинг или кодогенерация», чем про нормальные родные обобщения. К тому же, никто не заставляет их сразу использовать.
              • 0
                Кодогенерация это инструмент, а не конструкция языка. Как-то специально его изучать в рамках дисциплины программирования смысла нет.
            • 0
              Скажите пожалуйста, когда последний раз, в реальном проекте, вы действительно были вынуждены писать свою структуру данных, которая действительно нуждается в обобщениях? Будьте добры, наведите юскейс.
              • +4
                Как минимум год назад, но суть не в этом. Речь идёт про обучение, где нужно понять, как такие вещи в принципе делаются, прежде чем бросаться использовать библиотечные функции.
                • –6
                  Я не вижу потребности в обобщенном программировании при обучении.
                  • +5
                    Давайте тогда уже и механизм исключений не изучать, раз его в Go не завезли. И наследование, и алгебраические типы, и функциональное программирование. Вы понимаете, какова вообще суть обучения?
                    • –8
                      Мы говорим про обучение программированию в принципе или на конкретном ЯП? Что исключения, что алгебраические типы, что функиональщина — это специфические для того или иного ЯП фишки.
                      • +4
                        Go достаточно многословный и строгий язык программирования с очень предсказуемой и стремительной кривой обучения, что делает его крайне удачной технологией для обучения программированию новоприбывших!

                        Я так понял контекст, что речь идёт о программировании в целом. Исключения есть практически во всех широко используемых языках, проще перечислить, где их нет (Go, Rust, что ещё?). Алгебраические типы также есть во многих языках: Scala, Erlang, Haskell, Rust, etc. Сказать, что это специфические ЯП фишки — явное лукавство.
                        • –3
                          Я не могу понять суть ваших претензий, но да, в контексте речь о программировании в целом.
                        • +5
                          Как вы выражаетесь, «функциональщина» — это не специфические для ЯП «фишки», а целый подход к программированию, который планомерно ползет в языке, где раньше никакого ФП не было. И это и к лучшему.
                          • –1
                            Дело в том, что ФИШКИ из ФП есть далеко не везде и я не считаю необходимым в обязательном порядке их изучать.
                            • +3
                              Так не изучайте фишки, изучайте подход. Собственно, это ведь ровно для того и делается — чтобы знать, что еще бывает за пределами известных тебе языков, чтобы выбирать язык и инструмент под задачу.
                              • –1
                                Я вообще ничего против функциональных ЯП не имею, интересная область. Я просто считаю, что тут за уши функциональщину притянули. Изначальная претензия была формата: «а как это так ты собираешься учить программированию и не расскажешь про алгебраические типы, да?!», вообщем-то и притянутая за уши.
                                • +1
                                  А это как раз очень правильная по духу претензия. Обучая программированию надо рано или поздно показывать все более-менее распространенные инструменты, чтобы в будущем они не вызывали непонимания.
                                  • –1
                                    И какое это имеет отношение конкретно к языку Go, как языку для обучения программированию?
                                    • 0
                                      Вероятно, такое, что он не так хорошо для этого подходит, как вы пытаетесь показать?
                                      • –1
                                        Я не говорил, что Go это язык, который научит ВСЕМУ программированию. Функциональное программирование — это вовсе не необходимое, а скорее вероятное подмножество в соотв. навыке.
                                        • 0
                                          Знаете, а так можно о чем угодно сказать — что это вовсе не необходимое, а вероятное подмножество. Кроме умения думать, которому ни один язык не научит.

                                          Разговор, заметим, начался не с ФП, а с дженериков, обучение которым вы тоже не считаете нужным. Чем обосновано ваше «это не нужно» и «это нужно»?
                                          • –1
                                            Дженерики не то чтобы не нужны, скорее просто не необходимы. Программировать можно и без них, ровно как и без map/reduce. Конкретно дженерики вводят слишком много непрозрачности, чтобы навязывать их прямо-таки начинающим программистам.
                                            • +2
                                              Программировать можно много без чего. Как вы определяете, что нужно, а что нет в обучении?

                                              (И нет, не надо ничего навязывать, надо показывать возможности.)
                                              • –3
                                                Тут мы уже упираемся в мнения. Это мои личное ИМХО, у кого-то оно может быть другим.
                                                • +3
                                                  Вообще-то имхо неплохо бы обосновывать, раз уж вы с ним выходите в публичное пространство.
                      • +4
                        Понимаете, в чём ирония… Ладно бы там вообще не было обобщений, как в С. А то ж есть, вот они (map, array), но даны богом свыше и недостижимы простым смертным.
                        • –5
                          Словарь и массив это не обобщения, а стандартные структуры данных.
                          • +9
                            стандартные обобщённые структуры данных
                            • 0
                              Ничего «стандартного» в словарях, а особенно в словарях, где типы и ключа, и значения, задаются — нет. Точнее, есть — там, где есть дженерики.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • 0
                          На самом деле то, о чем вы сейчас говорите — это достаточно редкий случай, в котором можно даже кодогенерацию применить. Но в общем случае, список это slice типа interface{}. Оный удовлетворяет абсолютно любые переменные.
                          • 0
                            Постойте, а разве в Go нету встроенного обобщённого списка?
                            • +2
                              golang.org/pkg/container/list — он обобщает через interface{}
                              • +4
                                Ок, встроенными оказались только массивы (array) и отображения (map), насколько я вижу. Аскетичненько так.
                                • 0
                                  На самом деле массивами пользуются очень редко, потому что в них мало силы. Другое дело, слайсы! Но да, встроенных контейнеров больше нету.
                                  • 0
                                    Встроеные обобщённые типы — массивы/слайсы, мапы и каналы. Они действительно «даны свыше» и программист сам создать аналогичные типы не может, так устроен язык.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                • +3
                                  Грубо говоря, гошная статическая система типов в такой задаче сдаётся без боя.
                                  • 0
                                    Да, статический type switch:

                                    // element is interface{}
                                    
                                    switch casted := element.(type) {
                                    case int: {}
                                    case string: {}
                                    default: {}
                                    }
                                    
                                    • +3
                                      Постойте, постойте-ка, какой ещё статический? Компилятор, по вашему, знает о типе каждого элемента списка на этапе сборки? Ересь.
                                      • +1
                                        Глупость, глупость, глупость. Разумеется, динамический.
                                      • 0
                                        ну это совсем не комильфо… всё вроде строго, а тут БАЦ! и разные типы в контейнер помещаются…
                                        если в контексте обучения программированию, то это как-то сбить с толку может и выстроить в голове не правильные логические последовательности и паттерны мышления (контейнер -> нужно проверять тип элемента), которые в других языках будут не всегда работать (проверка типа такая нужно только ЯП с дин. типизацией, о которой Вы в контексте обучения отзываетесь не лестно). но это конечно имхо
                                        сколько ещё неоднородностей подобных язык таит в себе сей?
                                        • 0
                                          Вы просто не писали на Go. Приведенный выше пример — это «как можно», а не «как обычно». Обычно никто не использует такие слайсы (а следовательно и проверку типа), а обходятся строго типизированными.
                                • +3
                                  Скажите, а вам нравится буквально копипастить по несколько функций для того, чтобы воспользоваться, например, очередью с приоритетами?
                                • 0
                                  Для изучения алгоритмов и структур данных генерики не нужны (а скорее даже вредны, создают лишний оверхед и ухудшают эффективность структур данных).
                                  • 0
                                    Это зависит от их реализации.
                                    • 0
                                      Но ты согласен, что для изучения алгоритмов и структур данных они (генерики) не необходимы?
                                      • +1
                                        Это интересный вопрос.

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

                                        Так что я бы, наверное, сначала давал без дженериков, а потом бы их добавил.
                                • +1
                                  А организовать пробное обучение Go для тех, кто уже хоть как-то знает хоть какой-то ЯП, скажем в Питере, было бы занятно и познавательно.
                                  • –9
                                    "… Реализация требовалась на паскале, а я паскаль знаю очень плохо..."

                                    Уж лучше бы вы не позорили гоферов. После такой заявки как-то рассуждать о Go, как языке обучения, мягко говоря, не комильфо…

                                    Паскаль самое что ни на есть прямое подмножество языка Go, только нет интерфейсов и фигурные скобки заменяются на begin/end. Ну еще пара несущественных нюансов…
                                    • +4
                                      Вы сейчас говорите абсолютную ересь! Go действительно взял что-то от паскаля (не так уж и много, к слову), но это не делает последний его подмножеством.
                                      • –9
                                        Как вы можете утверждать много/немного, если сами говорите, что плохо знаете Паскаль?.. ))

                                        Единственное, что есть принципиального у Go, чего нет в Паскале — это интерфейсы, замыкания и, в большинстве реализаций Паскаля, функций как базового типа. Всё остальное то же самое, кроме того, что в Паскале:

                                        — Присваивание :=
                                        — Точка с запятой в конце инструкции ставится всегда
                                        — Переменные объявляются всегда
                                        — Есть цикл while

                                        Остальные различия чисто косметические…
                                        • +7
                                          Из вашего комментария понял, что паскаль это как Go, только без первого, второго… пятого и десятого, зато присваивание := и точка с запятой есть.

                                          • –3
                                            Ну, уже неё плохо… Если бы вы были ещё знакомы с JavaScript, то вы бы ещё поняли про замыкания и тип функция. А интерфейсы это из java…
                                          • +4
                                            Go и Pascal это два совершенно разных языка. Pascal действительно оказал влияние на Go, но это влияние не составило и десятой части того, что вложили в спецификацию Go.
                                            • +1
                                              Ну, Go это всё равно такой Паскаль с каналами, горутинами и сборщиком мусора :) Мне такого языка не хватало во времена, когда я писал на Паскале — и я ушёл в Java. А сейчас Go — это такой Паскаль, с фичами от JVM-языков.
                                            • +6
                                              В Go := не является присваиванием как раз, в отличае от Паскаля. В Go := является объявлением переменной c одновременной её инициализацией, а не присваиванием.

                                              А вот присваивание в Go это =
                                              • –2
                                                Читайте внимательно комментарии, на которые отвечаете. Где я написал что в Go := это обычное присваивание?
                                                • +3
                                                  — Присваивание :=

                                                  В Go := это вообще не присваивание. Это инициализация + объявление переменной.
                                                  • 0
                                                    >>Всё остальное то же самое, кроме того, что в Паскале:

                                                    >>— Присваивание :=

                                        • –6
                                          Отсутствие классов есть недостаток. Все-таки, в реальном мире программирования, классы используются очень часто, и ООП надо учить «с пеленок» (программистских). Я бы сказал, что это одна из основ программирования в принципе, которая неразрывно связана с моделированием объектов (в т.ч. реального мира) и их использованием.
                                          • 0
                                            На самом деле, класс — это очень абстрактное понятие. Go это полноценный ООП язык, который реализует инкапсуляцию, наследование, полиморфизм и все вот эти ООПшные примочки.
                                            • 0
                                              Я Вам поверю, т.к. не очень хорошо знаком с Go. Есть ссылочка почитать об этом кратенько? Прямо вот чтобы за пару минут понять и просветлиться.
                                          • +4
                                            После того, как я поработал с Go, стало очевидно, что то ООП, которое нам продают другие языки — оно не совсем правильное :)
                                            Многие ассоциируют ООП с наследованием, а Go ассоциирует его с интерфейсами. И сейчас я соглашусь с авторами Go, что это гораздо правильнее. Правильнее не с точки зрения определения ООП, а с точки зрения построения архитектуры приложения и его будущего развития. Наследование чаще приносит больше вреда, нежели пользы. Я вообще не видел ни одного примера большого приложения, где наследование использовалось бы только там, где это нужно — обязательно кто-то поленится и вместо поддержки интерфейса просто отнаследуется, а потом эту «архитектуру» приходится поддерживать.
                                            • +1
                                              Практически все паттерны в Go реализуются тем же путём, как и в ООП языках. habrahabr.ru/post/240917
                                            • +1
                                              > Потрясная кривая обучения
                                              Было бы интересно посмотреть на эту кривую. Не могли бы Вы описать план курса по основам программирования на go?
                                              • +3
                                                очень классно было бы, если бы Вы попробовали научить кого-нибудь из младших братьев/сестёр (не своих, так друзей) и предоставили бы результаты «исследования»: в каких моментах именно go дети чаще ошибаются, что даётся сложнее/проще и тд
                                                а так получается агитация и мало доказательств
                                                • 0
                                                  О том, что опытный программист полностью осваивает Go, со всеми его подводными камнями, за несколько выходных, уже неоднократно говорили

                                                  А есть ли ссылки на подобный опыт «изучения за несколько выходных»?
                                                  • +3
                                                    Это бред. За несколько выходных можно начать писать на Go. А вот чтобы начать писать на нем «красиво» — нужно хотя бы месяца 3 на нем поработать. И да, подводных камней немного, но они есть и за несколько выходных их все не обойдешь.
                                                    • +4
                                                      Поясню почему спросил: я тот самый «опытный программист» (39 лет, проф. стаж 17 лет, общий стаж программирования 24 года), но вот от Go меня просто «воротит». Так что хотелось бы каких-то «success stories» про изучение Go в кратчайший сроки или что-то вроде того.
                                                      • 0
                                                        Сакцесс стори такие, что разработчики, которые никогда на Go не писавшие — начинают это делать через 3-7 дней после знакомства с языком. Они конечно не асы после этого, но работать с языком уже могут. Есть несколько компаний, которые переходят на Go, с подобным успешным опытом.
                                                        Хотелось бы поинтересоваться отчего вас воротит? И какой у вас бэкграунд языковой?
                                                        • +4
                                                          Оставим мою персону за рамками обсуждения. Меня интересует только:
                                                          О том, что опытный программист полностью осваивает Go… за несколько выходных, уже неоднократно говорили

                                                          Где говорили, ссылки, кто говорил, кто переходил?
                                                  • +6
                                                    Помнится, год назад автор так же восторженно восхвалял Qt, заявляя что всем срочно нужно прыгать на кресты.
                                                    Теперь вот Go.

                                                    Интересно, что будет дальше. Господа, сделаем ставки?
                                                    • +1
                                                      Интересно, что будет дальше

                                                      Nim?
                                                      • 0
                                                        Экосистема слабовата имхо

                                                        Хотя я не адепт, может у них все хорошо.
                                                      • –3
                                                        год назад автор так же восторженно восхвалял Qt, заявляя что всем срочно нужно прыгать на кресты.

                                                        Насколько сильно я вас заставлял переходить на Qt и кресты, в частности?
                                                        Теперь вот Go.

                                                        Повторяю предыдущий вопрос: заставлял ли я вас сейчас «прыгать» на Go?
                                                        • +3
                                                          ты должен пересесть со своих Java/Obj-C/.NET на мягкий и пушистый Qt.


                                                          Не знаю, это насколько сильно?
                                                      • +2
                                                        Меня учили на примере Паскаля и на тот момент это был, пожалуй, наилучший выбор.

                                                        Я считаю, что первый язык для обучения должен обладать следующими качествами:
                                                        1. Быть не слишком сложным (ну это очевидно). Поэтому C/C++ отпадают.
                                                        2. Но в то же время не слишком упрощенным, не «детским» — а пригодным для реальной коммерческой разработки. То есть учебный опыт должен быть не чисто игровым («а теперь забудьте всё, что учили раньше, сейчас мы займёмся нормальными вещами»), а практическим. Например, в наше время некоторых ещё учили на Бейсике, хотя он уже был полностью устаревшим и неактуальным. Поэтому же отпадают все слишком экзотические языки.
                                                        3. Обязательно быть типизированным. Учащийся должен хорошо различать различные структуры данных и понимать, что автоматическое приведение типов — это плюшка, а не данность. Не должно быть поначалу слишком много скрытой магии.
                                                        4. Обязательно иметь понятие указателя. Даже в нынешнюю эпоху сборщиков мусора учащийся должен получить базовое представление о работе с памятью, что происходит «под капотом», о передаче по ссылке/значению. Не сразу в хардкорной версии C++, но должен.
                                                        5. Быть процедурным, поскольку это самая простая, естественная и логичная идеология.

                                                        Так что да, Go — это очень хорошая кандидатура.
                                                        • +1
                                                          Go не процедурный все же. Есть и привязка методов к структурам и наследование через композицию.
                                                        • +6
                                                          Проблему инкапсуляции решили до безобразия интересно: все поля структуры, которые начинаются с символа верхнего регистра идут наружу, а все остальное остается внутри.

                                                          Это не «решили проблему инкапсуляции», это «придумали еще одну конвенцию». Это никак не отвечает на вопрос «какие поля надо прятать, а какие — нет» — который, собственно, является проблемой инкапсуляции.
                                                          • –1
                                                            Ты конечно же прав.

                                                            Конкретно в данном случае я имел ввиду под «проблемой» инкапсуляции то, что сходу сказать, можно использовать метод или нет, нельзя и был не очень прав, потому что это не проблема вовсе.
                                                          • +2
                                                            Лично я считаю, что лучшим обучающим языком программирования является Python, тут и REPL, и достаточная высокоуровневость позволяющая не задумываться об ньюансах реализации, концентрируясь на сути алгоритмов, и хорошая реализация различных парадигм программирования, более чем подходящаяя для введения в них, и громадное количество библиотек, которые позволят сразу решать интересные обучающемуся проблемы (начиная от игр, и заканчивая научными вычислениями, обработкой и визуализацией данных), ну и разумеется практическая применимость самого языка в широком спектре областей. Да, на его примере нельзя будет толком рассказать о компиляции в машинные коды, о статической типизации, и о многих других вещах, но, не думаю, что всё это больше технические детали, достойные углубленных курсов, нежели чем жизненно необходимые вещи для начинающих.

                                                            Презентация же Go как обучающего языка (и, например, как по-настоящему системного), на мой взгляд, это чистое натягивание ежа на ужа, которое будет делать языку больше вреда, чем пользы, ибо рекламируя язык в неподходящих областях, создаётся дурная репутация, которая будет автоматически распространяться и на области где этот язык чрезвычайно хорошо.
                                                            • +2
                                                              Я тут посмотрел перечень всех статей автора данной статьи и обнаружил одну интересную для меня вещь. Этому автору, оказывается, 16-17 лет отроду. Он школьник, даже не студент. Вот статья от 10-го мая 2013-го года, где он прямо говорит:
                                                              Меня зовут Илья Ковалевский, я ученик 8-Б класса киевского лицея

                                                              Так что относитесь к предложению о Go как лучшем языке для обучения как к личному опыту автора :)
                                                              • 0
                                                                Мне 16 лет, я действительно школьник и не в коем случае не студент, но когда я начал учить Go у меня уже было за плечами 3 года опыта работы с С++, из них 2 — в FOSS.
                                                                • +2
                                                                  Хм… Мой пардон… Тогда снимаю свой, можно сказать, «наезд» на счет Паскаля. В вашем случае это вполне нормально, вы еще не профессиональный разработчик.

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

                                                                  В общем я с вами согласен. Go — хороший язык для изучения в качестве первого языка. Пока не дойдет до конкурентных вычислений. Там уже требуется иметь теоретический бэкграунд. Параллельные/многопоточные вычисления это отдельная дисциплина…
                                                                  Главный же плюс Go, в отличие от того же Паскаля — это актуальность…
                                                              • +2
                                                                WTF am I reading?

                                                                >>В Go нету указателей, а только ссылки.

                                                                >>Go has pointers. A pointer holds the memory address of a variable.

                                                                tour.golang.org/moretypes/1

                                                                • 0
                                                                  Черт, а тут я тут похоже облажался. Дело в том, что в С++ ссылка (reference) может указазывать только на один и тот же самый объект, а в случае с указателем (pointer) — это не так. Поэтому мне кажется, что указатель в Go это скорее ссылка, нежели указатель (в контексте С++, например). Я не прав?
                                                                  • +2
                                                                    поэтому мне кажется, что указатель в Go это скорее ссылка, нежели указатель (в контексте С++, например)

                                                                    Т.е. вы хотите сказать, что в Go нет возможности изменить значение переменной, содержащей указатель?
                                                                    Почему тогда следующий код работает:
                                                                    package main
                                                                    import "fmt"
                                                                     
                                                                    func main() {
                                                                    	x := 5
                                                                    	y := 7
                                                                    	p := &x
                                                                    	fmt.Printf("%v\n", *p)
                                                                    	p = &y
                                                                    	fmt.Printf("%v\n", *p)
                                                                    }
                                                                    
                                                                    ?
                                                                    • 0
                                                                      Все верно, я просто опять запутался в этих определениях. Да, все-таки указатели, пойду поправлю статью, спасибо!
                                                                • 0
                                                                  А что в контексте замены обобщений называется «бутсрапингом»?
                                                                  • +4
                                                                    > Жестко? Еще бы! Но знаете, такая жесткость, она воспитывает!

                                                                    Воспитывает что? Ненависть к программированию?
                                                                    Сколько часов в школе программирование нынче, что на это времени не жалко?

                                                                    > «а как наследовать два класса одновременно???»

                                                                    А в Go проще что ли?

                                                                    type Reader interface {
                                                                    Read(p []byte) (n int, err error)
                                                                    }

                                                                    type ReaderInv interface {
                                                                    Read(p []byte) (n int, err error) // Читаем в обратном порядке
                                                                    }

                                                                    type MultiReader struct {
                                                                    Reader
                                                                    ReaderInv
                                                                    }

                                                                    И, наконец, я хочу сделать как-то так:
                                                                    switch t := t.(type) {
                                                                    case Reader:
                                                                    t.Read(...)
                                                                    case ReaderInv:
                                                                    t.Read(...)
                                                                    case MultiReader:
                                                                    t.Read(...)
                                                                    }

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

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