Это первое, на что я обратил внимание в этой статье. Статья явно не стоит внимания! Пол статьи рассказывается про структуры данных. Назвать статью надо было "Дженерики и структуры данных в Go" или как-то так... Автор, а как же читателю понять может ли он свой тип создать, чтобы он удовлетворял ограничение comparable? Информации - ноль. Зачем эта статья!?
Отличная статья! Я как-раз вчера решил с вима на неовим перейти попробовать. Плюс к карме сразу! Вот только у меня иконок не хватает у диагностических сообщений в строках кода...
Нет, я не ошибаюсь. Вы, возможно, плохо знакомы с Go, и Вам кажется, что Go ООП-язык, он похож на него и можно написать программу как-будто на ООП-языке, но это не так…
В Go нет абстракции, явной инкапсуляции (здесь это лишь синтаксический сахар) и наследования (есть внедрение структур, не надо путать с наследованием).
Почитайте повнимательнее.
Наследование, конструкторы и деструкторы из мира ООП. Го не ООП язык! О чем статья? О сравнении ООП языков с не ООП языками? Дженерики будут в Go 2. Остальное — усложнение языка, что протеворечит философии Го… Статья ни о чем!
Можно конечно, но сохранить результаты этих функций не получится. Я думаю, отсутствие данной возможности связано с философией простоты языка. Но раз уж дженерики собрались сделать, то и это можно было бы...
И правда, например, порой прежде чем кодить 2 часа, можно посидеть подумать 30 минут и написать работающий код за 30 минут. Вот вам и 2 раза быстрее и скорее всего качественнее.
Полагаю, что качественно просто не умеет рынок делать… Мало таких специалистов.
Аргумент "давайте сделаем быстро, плохо и заработаем денег быстрее" совершенно понятен! Но, меня никто никогда не сможет заставить сделать плохо, я вот не умею так… Пускай так и будет. Каждый должен занять свое место!
Речь о среднестатистическом студенте, а не о специальности АСУ в МГУ… Вы в праве иметь собственный подход к преподаванию,, конечно же. Практика покащывает, что студент, который хочет программировать либо спросит, либо разберется, либо к нему другие пожелания преподавателя, в тч те, о которых, говорите Вы.
Думаю, любой преподаватель укажет на это, но на зачет влиять не будет. В случае какой-нибудь школы программирования, конечно подобное недопустимо, как и любые другие общеизвестные правила написания кода.
Это очень хорошо! Значит, меняйте решение, если конечно, архитектура, построенная на выбранных с помощью неких аргументов и "принципах" ООП, позволит Вам это сделать…
Это материал для песочницы. Уровень низкий
Это первое, на что я обратил внимание в этой статье. Статья явно не стоит внимания! Пол статьи рассказывается про структуры данных. Назвать статью надо было "Дженерики и структуры данных в Go" или как-то так... Автор, а как же читателю понять может ли он свой тип создать, чтобы он удовлетворял ограничение comparable? Информации - ноль. Зачем эта статья!?
Ага, МИКРОсервисы на джава машине с серваком 64Гб ОЗУ! ))
Пробовал Ваш шрифт - не работают все-равно
Отличная статья! Я как-раз вчера решил с вима на неовим перейти попробовать. Плюс к карме сразу! Вот только у меня иконок не хватает у диагностических сообщений в строках кода...
Статья жиденькая, конечно, но попытка формализации такой важной темы достойна уважения! Развивайте идею!
Нет, я не ошибаюсь. Вы, возможно, плохо знакомы с Go, и Вам кажется, что Go ООП-язык, он похож на него и можно написать программу как-будто на ООП-языке, но это не так…
В Go нет абстракции, явной инкапсуляции (здесь это лишь синтаксический сахар) и наследования (есть внедрение структур, не надо путать с наследованием).
Почитайте повнимательнее.
https://golang.org/doc/faq#Is_Go_an_object-oriented_language
Наследование, конструкторы и деструкторы из мира ООП. Го не ООП язык! О чем статья? О сравнении ООП языков с не ООП языками? Дженерики будут в Go 2. Остальное — усложнение языка, что протеворечит философии Го… Статья ни о чем!
Да, это нормальный пример! Но, опять же, в других языках такая же ситуация и ничего. Возможно, из Go решили сознательно убрать эту возможность...
В любом языке так. В if вряд ли стоит делать проверки типа a == false, это !a и только так.
Есть способы, конечно же! Хочется попроще...
Можно конечно, но сохранить результаты этих функций не получится. Я думаю, отсутствие данной возможности связано с философией простоты языка. Но раз уж дженерики собрались сделать, то и это можно было бы...
Я бы очень хотел иметь такую возможность:
Так и должно быть! Иначе, будет означать, что нет развития.
И правда, например, порой прежде чем кодить 2 часа, можно посидеть подумать 30 минут и написать работающий код за 30 минут. Вот вам и 2 раза быстрее и скорее всего качественнее.
Полагаю, что качественно просто не умеет рынок делать… Мало таких специалистов.
Аргумент "давайте сделаем быстро, плохо и заработаем денег быстрее" совершенно понятен! Но, меня никто никогда не сможет заставить сделать плохо, я вот не умею так… Пускай так и будет. Каждый должен занять свое место!
Речь о среднестатистическом студенте, а не о специальности АСУ в МГУ… Вы в праве иметь собственный подход к преподаванию,, конечно же. Практика покащывает, что студент, который хочет программировать либо спросит, либо разберется, либо к нему другие пожелания преподавателя, в тч те, о которых, говорите Вы.
Думаю, любой преподаватель укажет на это, но на зачет влиять не будет. В случае какой-нибудь школы программирования, конечно подобное недопустимо, как и любые другие общеизвестные правила написания кода.
Это очень хорошо! Значит, меняйте решение, если конечно, архитектура, построенная на выбранных с помощью неких аргументов и "принципах" ООП, позволит Вам это сделать…