Я вообще ничего против функциональных ЯП не имею, интересная область. Я просто считаю, что тут за уши функциональщину притянули. Изначальная претензия была формата: «а как это так ты собираешься учить программированию и не расскажешь про алгебраические типы, да?!», вообщем-то и притянутая за уши.
Черт, а тут я тут похоже облажался. Дело в том, что в С++ ссылка (reference) может указазывать только на один и тот же самый объект, а в случае с указателем (pointer) — это не так. Поэтому мне кажется, что указатель в Go это скорее ссылка, нежели указатель (в контексте С++, например). Я не прав?
Мне 16 лет, я действительно школьник и не в коем случае не студент, но когда я начал учить Go у меня уже было за плечами 3 года опыта работы с С++, из них 2 — в FOSS.
Конкретно в данном случае я имел ввиду под «проблемой» инкапсуляции то, что сходу сказать, можно использовать метод или нет, нельзя и был не очень прав, потому что это не проблема вовсе.
На самом деле, класс — это очень абстрактное понятие. Go это полноценный ООП язык, который реализует инкапсуляцию, наследование, полиморфизм и все вот эти ООПшные примочки.
Мы говорим про обучение программированию в принципе или на конкретном ЯП? Что исключения, что алгебраические типы, что функиональщина — это специфические для того или иного ЯП фишки.
На самом деле то, о чем вы сейчас говорите — это достаточно редкий случай, в котором можно даже кодогенерацию применить. Но в общем случае, список это slice типа interface{}. Оный удовлетворяет абсолютно любые переменные.
Go и Pascal это два совершенно разных языка. Pascal действительно оказал влияние на Go, но это влияние не составило и десятой части того, что вложили в спецификацию Go.
Конкретно в данном случае я имел ввиду под «проблемой» инкапсуляции то, что сходу сказать, можно использовать метод или нет, нельзя и был не очень прав, потому что это не проблема вовсе.
Насколько сильно я вас заставлял переходить на Qt и кресты, в частности?
Повторяю предыдущий вопрос: заставлял ли я вас сейчас «прыгать» на Go?