Почему вам стоит изучить Go?

Всем привет! Представляю вашему вниманию мой перевод статьи (включая графики) Кевала Патела Why should you learn Go? Статья содержит много интересных фактов, которые, по моему мнению, будет полезно узнать новичкам в Go.

P.S.: Статья, как и большинство статей, на мой взгляд, отражает опыт и мнение автора, которое может не совпадать с вашим, и это нормально — сколько людей, столько и мнений.
Gophers

Изображение взято с ресурса kirael-art.deviantart.com/art/Go-lang-Mascot-458285682

“Go станет серверным языком будущего.” — Tobias Lütke, Shopify

За последние пару лет произошёл мощный рост нового языка программирования: Go, или Golang. Согласитесь, ничто так не может свести с ума разработчика, как новый язык программирования. Поэтому, я начал изучать Go 4-5 месяцев назад и вот что я могу сказать о том, почему вам стоит изучить этот новый язык.

В этой статье я не собираюсь учить вас, как написать «Привет, мир!!». Есть много других статей об этом. Я собираюсь прояснить текущее состояние компьютерного аппаратного и программного обеспечения и зачем вам такой новый язык, как Go. Ведь если нет проблем, то и решения не нужны, верно?

Ограничения железа:


Закон Мура не работает.

Первый процессор Pentium 4 с тактовой частотой 3.0 ГГц был представлен ещё в 2004 году компанией Intel. Сегодня, мой Macbook Pro 2016 имеет тактовую частоту 2.9 ГГц. Таким образом, около десятилетия нет особого прогресса чистой вычислительной мощности. Ниже на графике, вы можете увидеть сравнительный график роста вычислительной мощности по времени.

Сравнительный график роста вычислительной мощности по времени

По графику можно понять, что однопоточная производительность и частота процессора оставалась стабильной почти десятилетие. Если вы думаете, что добавить больше транзисторов — это хорошее решение, то вы ошибаетесь. Так происходит потому, что в более меньших масштабах начинают проявляться квантовые свойства объекта (такие как туннелирование, [или туннельный эффект. — прим.перев.]), а добавление большего количества транзисторов действительно может привести к дополнительным расходам (почему?) и количество транзисторов, которые вы можете добавить за один доллар стремительно начинает падать.

Поэтому, для решения проблемы выше,

  • Производители начали добавлять больше ядер в процессор. На текущий день нам доступно 4-х и 8-ми ядерные процессоры.
  • Также положено начало гиперпоточности.
  • Добавили больше кэша в процессор для увеличения производительности.

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

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

“Современные процессоры похожи на забавные автомобили, заправленные нитро, — они превосходны в гонке на четверть мили. К сожалению, современные языки программирования, как трасса Монте-Карло — полны изгибов и поворотов.”  —  David Ungar

В Go есть горутины !!


Как говорилось ранее, производители аппаратного оборудования добавляют всё больше ядер в процессор, чтобы увеличить его производительность. Все дата-центры запускаются на этих процессорах и нам стоит ожидать увеличения количества ядер в ближайшие годы. Более того, современные приложения используют множество микросервисов для поддержки соединений с базой данных, очередей сообщений и кэширования. Таким образом, разрабатываемые нами программное обеспечение и языки программирования должны легко поддерживать многозадачность (concurrency. — прим. перев.) и они должны быть масштабируемыми при увеличении количества ядер.

Но большинство современных языков программирования (такие, как Java, Python) пришли из однопоточной среды разработки 90-х. Хотя большинство этих языков поддерживают многопоточность, но реальная проблема связана с одновременным выполнением, блокированием потока, состоянием гонки и тупиковой ситуацией. Эти вещи осложняют создание многопоточного приложения на вышеназванных языках.

Например, создание нового потока в Java неэффективно использует память. Поскольку каждый поток потребляет примерно 1МБ памяти из кучи (динамически распределяемой памяти. — прим. перев.) и в итоге, если вы запустите тысячи потоков, то они окажут колоссальное давление на память и могут вызвать завершение работы приложения из-за её нехватки. К тому же, если вы хотите, чтобы два или более потока могли общаться между собой, то сделать это будет довольно трудно.

С другой стороны, Go был выпущен в 2009 году, когда многоядерные процессоры были уже доступны. Вот почему Go был создан с учётом многозадачности (concurrency. — прим. перев.). Go использует горутины вместо потоков. Они потребляют почти 2КБ памяти из кучи. Поэтому, вы можете прокручивать хоть миллионы горутин в любое время.

Как работают горутины?

Как работают горутины? Подробнее: golangtutorials.blogspot.in/2011/06/goroutines.html

Другие преимущества:

  • Горутины имеют расширяемые сегментированные стеки. Это означает, что они будут использовать память только по необходимости.
  • Горутины имеют более быстрое время запуска, чем потоки.
  • Горутины поставляются со встроенными примитивами для безопасного обмена данными между собой (каналы).
  • Горутины позволяют избежать необходимости прибегать к блокированию мьютексов при совместном использовании структур данных.
  • Также, горутины и потоки ОС не имеют сопоставления 1:1. Одна горутина может запускаться во множестве потоков. Горутины объединены (multiplexed. — прим.перев.) в малое количество потоков ОС.

Вы можете посмотреть отличное выступление Роба Пайка Многозадачность — это не параллелизм, чтобы более глубоко разобраться в этой теме.

Все вышеупомянутые пункты делают Go очень мощным для обработки многозадачности так же, как в Java, С и С++, и в то же время сохраняя красоту и естественность кода, как в Erlang.

График многозадачности против эффективности
Go вобрал в себя лучшее из обоих миров. Одновременно лёгкий в написании и эффективный в управлении многозадачностью

Go запускается непосредственно на железе.


Одно из самых значимых преимуществ использования С/С++ вместо современных языков, типа Java/Python, это их производительность. Потому что С/С++ компилируются, а не интерпретируются.

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

Этапы выполнения кода, основанных на JVM
Этапы выполнения кода, основанных на JVM

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

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

Go вобрал лучшее из обоих миров. Как и низкоуровневые языки, типа С/С++, Go компилируемый язык. Это подразумевает производительность, близкую к низкоуровневым языкам. Он также имеет свой сборщик мусора для распределения и удаления объектов. Больше malloc() и free()! Круто!

Код, написанный на Go, легко поддерживать.


Позвольте мне сказать вам одну вещь. У Go нет такого безумного синтаксиса, как в других языках, — всё очень аккуратно и чисто.

Разработчики Go в Google имели это ввиду, когда создавали его. Ввиду того, что у Google огромная кодовая база и над ней трудятся тысячи разработчиков, то код должен быть простым для понимания остальными разработчиками, и один участок кода должен иметь минимум побочных эффектов на другие участки. Это делает код более простым для поддержки и внесения изменений.

Go намеренно не содержит множество особенностей ООП языков.

  • Нет классов. Каждая вещь делится только на пакеты. Вместо классов Go использует только структуры (structs. — прим.перев.).
  • Не поддерживает наследование. Это упрощает модифицирование кода. В других языках, типа Java/Python, если класс ABC наследует класс XYZ, и вы при этом делаете какие-то изменения в классе XYZ, то это производит дополнительное изменения во всех наследованных от него классах. К тому же, без наследования, код Go становится более простым для понимания (так как нет super классов, на которые нужно обращать внимание при изучении участков кода).
  • Нет конструкторов.
  • Нет аннотаций.
  • Нет дженериков (универсальных шаблонов. — прим.перев.).
  • Нет исключений.

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

График читабельности кода против его производительности
Читабельность кода против его производительности.

График выше показывает, что Go почти так же эффективен как С/С++, и имеет такой же простой синтаксис, как Ruby, Python и другие языки. Это беспроигрышный вариант (win-win. — прим.перев.) как для людей, так и для компьютера!

Синтаксис Go очень стабилен, чего не скажешь о другом новом языке Swift. Синтаксис не изменился с момента его публичного релизе версии 1.0 в 2012 году. Это наделяет его обратной совместимостью.

Go поддерживается Google.


  • Я знаю, что это не совсем техническое преимущество. Но Go разработан и поддерживается Google. У Google самая большая облачная инфраструктура в мире и она всё ещё расширяется. Google создала Go для решения их собственных проблем с поддержкой масштабируемости и эффективности. С этими же проблемами вам придётся столкнуться и при создании своего собственного сервера.
  • Более того, Go используется такими компаниями, как Abode, BBC, IBM, Intel и даже Medium. (Источник: github.com/golang/go/wiki/GoUsers)

Заключение:


  • Хотя Go отличен от других ООП языков, это всё тот же зверь. Go предоставляет вам такую же высокую производительность, как в С/C++, высокоэффективную обработку многозадачности, как в Java и такое же удобство написания кода, как в Python/Perl.
  • Если вы не планируете изучать Go, то я всё же скажу, что лимит аппаратного обеспечения оказывает давление на нас, разработчиков ПО, которые хотят писать очень эффективный код. Разработчику нужно понять железо и соответственно оптимизировать свою программу. Оптимизированное ПО можно запустить на дешёвом и медленном устройстве (типа IOT), что в целом лучше влияет на опыт взаимодействия конечного пользователя (UX. — прим.перев.).
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 332
  • +22
    1) «you should» != «вы должны»
    2) беглое прочтение статьи показывает что из всего перечисленного для Go уникальным является только «Go поддерживается Google.», это (без иронии) мощный агрумент.
    • +4
      • 0
        ну пока язык не на кладбище — поддержка гугла ему только в помощь. а что будет дальше — жизнь покажет.
        • +5
          Dart тоже поддерживается Google
          • –2
            Извините, но вы сейчас привели глупое сравнение. У всех людей могут быть идеи как благоприятно восприняты обществом, так и нет. И к слову Dart мог быть очень популярным языком, если бы не одна история во время его разработки.
            • +6
              если бы не одна история во время его разработки.

              За языком не следил, но любопытно. Можно в двух словах?

              • +2
                Присоединюсь, тоже любопытно.
                • +1
                  Самому стало интересно, нашел только https://arc.applause.com/2015/03/27/google-dart-virtual-machine-chrome/
                  Как я понял, гугл не захотел добавлять виртуальную машину для Dart в хром
                  • +2
                    image
                    • 0
                      По поводу Dart, Андрей Листочкин думаю расскажет лучше меня.
                    • +2
                      можно ссылку на историю для тех, кто не в курсе, но интересуется?
                      • +2
                        Извините, но вы сейчас привели глупое сравнение

                        Почему глупое? Я просто акцентировал на том, что факт поддержки Гуглом ничего не означает
                        • –1
                          Ну почему ничего не означает, всё субъективно и нельзя одно футболку одеть на всех. К примеру либы в dart поддерживаются гуглом, и это преимущество перед опен-сорсом npm. Потому что это означает стабильность и ясность направления библиотеки в отличии от npm. Согласитесь что такая компания как гугл не будет прекращать разработку чего-то вот так вот просто без слов, потому что «не хочется» или «нет настроения».
                          • +4

                            Зато может потому что "не окупается" или "нет коммерческой перспективы".

              • +36
                Изображение «Красота и естественность кода» мне кажется очень холиварная.
                Тоже самое могу сказать и про изображение «Эффективность и производительность для компьютера»
                • +8
                  Да там вообще всё отвратительно.

                  Настолько, что даже читать не стал вообще.
                • +43
                  Go запускается непосредственно на железе

                  Rust тоже.


                  Код, написанный на Go, легко поддерживать.

                  Сложно назвать легко поддерживаемым код на языке, в котором можно случайно забыть написать «if err != nil». Rust за это надаёт по ушам ещё при компиляции, да даже C++ выкинет исключение во время работы.


                  Классов в Rust нет, наследования нет, конструкторов нет, исключений тоже нет (про остальное точно не помню)


                  Go почти так же эффективен как С/С++

                  Rust тоже


                  Синтаксис Go очень стабилен

                  Подозреваю, синтаксис Rust ещё более стабилен)


                  Go поддерживается Google

                  Rust поддерживается Mozilla и целым сообществом и используется много кем


                  Горутины, думаю, можно заменить на Futures и в будущем async/await.


                  А ещё у Rust zero-cost abstractions и отсутствие gc.


                  И почему же мы должны учить Go, а не Rust? :)


                  (на правах вброса:)

                  • –8
                    Сложно назвать легко поддерживаемым код на языке, в котором можно случайно забыть написать «if err != nil».

                    Ну, вроде как, Go все же возмутится за неиспользование переменной err на уровне сборки.


                    И почему же мы должны учить Go, а не Rust? :)

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

                    • +17
                      Вот интересная ситуация. Низкий порог вхождения в php записывают ему в минусы и постоянно тычут этим. А у go это уже плюс. Двойные стандарты.
                      • 0

                        Лично я не записывал и не тыкал, просто выразил мнение. Но Растариане не дремлют :)

                        • +4

                          Мне б кто-то объяснил за что минусы ставят, может я бы и переосмыслил точку зрения? Не могу понять в чем я не прав.

                          • +3
                            Я это не лично вам писал. Просто часто сталкиваюсь с этим доводом в обоих его представлениях. И вот стало интересно отношение аудитории к этому.
                          • 0
                            Скорее порог вхождения не должен являться аргументом при рассмотрении самого языка. Например, высокий порог вхождения в Haskell совсем не делает его хуже в своем классе задач.

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

                            Если она была присвоена — да, а если нет — то нет.

                            foo()


                            Если функция `foo` возвращает значение типа `error`, то этот код вполне себе скомпилируется. Правда, для обнаружения таких проблем есть линтер: https://github.com/kisielk/errcheck
                          • –4
                            Все эти неоспоримые плюсы перекрывает сложность написания и сложность чтения когда на Rust. Увы, но в таком виде он не пойдет в массы, ибо Rust не для средних умов, а таких большинство.
                            • +9

                              А это ещё целая тема для срача, минус ли «не для средних умов» или таки плюс :D


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

                              • +8

                                Знаете, я вот совсем недавно интересовался, для каких языков есть клиентские библиотеки к docker. Среди тех, что мне были интересны, были и Go и Rust.


                                Де факто мой практический опыт для обоих языков почти одинаков и невелик. Так вот, для меня не было никакой сложности в том, чтобы читать код на обоих. И Rust ничем тут не сложнее. Я больше скажу — думаю что для тех, кто видел java generics (или другие языки с параметризованными типами данных, скалу скажем или хаскель), или алгебраические типы, знает хоть один язык из функциональных — читать Rust значительно проще.


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

                                • 0
                                  Ещё бы, докер то написан на Го.
                                  • +4

                                    Вы уверены, что поняли мой коммент? Клиент к докеру, написанный на Rust, не сложнее (а на мой личный вкус — проще), чем клиент к докеру, написанный на Go. То что Rust хуже
                                    сложнее читается — в значительной степени миф. Объемы кода сопоставимые.


                                    Так понятнее?

                              • +13
                                Go запускается непосредственно на железе
                                Rust тоже.

                                И на голом железе без особой потери функциональности. В отличии от Go, в котором есть сборка мусора.


                                if err != nil

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


                                А ещё там можно вызвать функцию от nil. И даже нормально обрабатывать это. Где-то в недрах stdlib даже используется.


                                конструкторов нет

                                Есть же. Но не как часть синтаксиса, а как часть хороших практик.


                                type Thing struct { a int }
                                
                                func NewThing() Thing { return Thing { 10 } }

                                struct Thing { a: isize }
                                
                                impl Thing {
                                  fn new() Self { Self { a: 10 } }
                                }

                                При этом в rust ещё и трейт Default есть.


                                исключений тоже нет

                                Но раскрутка стека есть. В golang перехватываемая при помощи recover. В rust убивает весь поток выполнения, но из родительского потока перехватывается. При этом в последнем есть оптимизации на этот счёт.


                                Go почти так же эффективен как С/С++
                                Rust тоже

                                Rust на текущий момент лишь чуть медленнее оных (примерно на разницу между llvm и gcc/msvc и компанией).
                                Go не особо быстр в сравнении с фаворитами, но намного быстрее скриптовых ЯП. Он больше про экономию памяти при общем удобстве, чем про чистую скорость в отличии от.


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


                                Подозреваю, синтаксис Rust ещё более стабилен)

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


                                Rust поддерживается Mozilla и целым сообществом

                                С корпорацией добра и зла не сравнить, да.


                                Горутины, думаю, можно заменить на Futures и в будущем async/await.

                                Пф. Уже есть https://github.com/dpc/mioco А каналы в stdlib присутствуют.


                                А ещё у Rust zero-cost abstractions и отсутствие gc.

                                И приятная боль от borrow-checker'а.


                                И почему же мы должны учить Go, а не Rust?

                                Сначала golang, потом rust. :3

                                • 0
                                  Спасибо за конструктивные дополнения!
                                  • +3
                                    Но раскрутка стека есть. В golang перехватываемая при помощи recover. В rust убивает весь поток выполнения, но из родительского потока перехватывается. При этом в последнем есть оптимизации на этот счёт.

                                    Начиная с 1.9.0 не верно, можно изолировать панику не на уровне нативного потока, см. https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

                                    • +1

                                      И еще всю раскрутку очень легко можно отключить через panic='abort', так что в общем случае в библиотеке на нее полагаться тем более не стоит.

                                      • 0

                                        Полагаться, ессно, не стоит. Для меня catch_unwind актуален, чтобы не произошла раскрутка через ffi'ную границу (сишный код дёргает callback моей библиотеки, которая дёргает пользовательский callback).

                                      • 0
                                        Основная проблема rust — посты про него устаревают ещё до их написания. Однако и это плюс. Ибо живой язык, не слишком обременённый обратной совместимостью.
                                        • +4
                                          С версии 1.0 добавляются / стабилизируются новые фичи, ничего не меняется и не удаляется, так что 99%, что писалось под 1.0, должно собираться до сих пор.
                                          • 0

                                            В смысле тонной легаси конечно. Не совсем правильно выразился.

                                    • 0
                                      Rust слишком многословен. Синтаксис Go действительно проще, порог входа ниже, и начать программировать на нем можно очень быстро. Когда я последний раз ковырял Rust, они постоянно что-то меняли, ломали совместимость и т.д. Не знаю, как с этим счас, это было давно. Плюс Go действительно заточен для написания приложений, работающих с сетью / микросервисов. Все, что нужно в нем есть из коробки. В прочем, в Go тоже есть куча своих проблем.
                                      • +5
                                        Когда я последний раз ковырял Rust, они постоянно что-то меняли, ломали совместимость и т.д. Не знаю, как с этим счас, это было давно.

                                        https://blog.rust-lang.org/2015/05/15/Rust-1.0.html — 1.0 давно уже вышел, с того времени строгая обратная совместимость поддерживается.

                                      • +1
                                        Осталось понять, зачем нужен Rust, когда уже есть С++ и огромное количество совместимых с ним библиотек :)
                                        Отсутствие ООП — странное преимущество, очень странное.
                                        • +4

                                          C++ позволяет выстрелить в ногу, если случайно забыть про меры предосторожности. Rust позволяет выстрелить в ногу, только если явно воткнуть в код стопицот предупреждений «да, я в здравом уме и твёрдой памяти хочу выстрелить в ногу ради всегобщего блага».


                                          А остальное касается любого другого языка, сабжа в том числе, и на ООП свет клином не сошёлся

                                          • +2

                                            ООП как таковое и не отсутствует. Отсутствуют классы и наследование. Вместо них трейты и композиция. Принципы ООП при этом никуда не делись.

                                            • 0
                                              Хм, ладно. Статья обходит это стороной, и можно подумать, что в Гугл переизобрели С.
                                              • 0

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

                                                • +1
                                                  основной целью ржавчинки является создание языка с… отсутствием утечек памяти

                                                  кхем, нет, с утечками железных гарантий не дают — https://habrahabr.ru/post/281370/

                                                  • 0

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

                                                    • 0

                                                      Смотря при каких условиях, можно просто запретить память в хипе выделять. И больше никаких утечек :^)

                                                      • 0

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

                                              • 0

                                                Наследование (на классах ли, на прототипах ли, может ещё на чём) — один из основных факторов отделяющих ООП от других парадигм.

                                                • +2

                                                  Возможность наследования есть у трейтов.

                                                  • 0

                                                    Значит наследование не отсуствует?

                                                    • +1

                                                      Только для трейтов, структуры/атд расширять нельзя.

                                              • 0
                                                Хз, наверное потому что за 30+ лет своего существования ООП так и не взлетела.

                                                Ну реально, в мейнстримовых интерпрайз языках все что можно было запретить в ООП — запретили, все что можно было порезать — порезали, ибо
                                                а) Наследование не работает. Ну реально, больше 2 ступенек иерархии наследования уже трудно-сопровождаемые (я как-то видел глубину наследования в 20+ классов — это был страшно), наличие наследования заметно заметно снижает скорость вызова функций (наплодить сотни тысяч и миллионов экземпляров класса СO2, который является наследником классов C и O, а те в свою очередь являются наследником абстрактного класса H и все это заставить моделировать термодинамику — увы и ах, но не получится), плюс к этому огребаем кучу неприятных моментов, как сильное связывание, хрупкие базовые классы и прочий рутинный трешняк
                                                б) Полиморфизм тоже не работает. С множественным наследованием нас обламалали, напридумывали всяких там еретических интерфейсов. В общем ромбик уже не тру
                                                в) Ну классы/типы вроде как какую-то пользу приносят, вот только всякие там структуры были еще задолго до этого вашего ООП
                                                г) В принципе использование ООП несет большие накладные расходы. Сейчас правда все ошалели от гигагерцев частоты и гигабайтов памяти… в итоге требования к ресурсам растут и растут, а вот функционал — нет. Если честно в программах с HPC все кладут болт на на это ООП и переходят на композицию

                                                Ну т.е. реально, на бумаге и когда рядом стоит умный архитектор, который сходу придумает структуру всего проекта и учтет все ньюансы, то ООП красиво выглядит, а вот когда надо выпустить совершенно новый продукт… в общем за 15 лет я еще ни разу не видел что бы ООП работало как обещали, а самые ответственные куски кода в итоге выполняются, например, как описано в этой статье https://habrahabr.ru/company/mailru/blog/319194/
                                                • +1
                                                  в общем за 15 лет я еще ни разу не видел что бы ООП работало как обещали

                                                  А как обещали?

                                                  • –2
                                                    На XXII съезде КПСС обещали построить коммунизм к 1980 году… но коммунизм так не построили, поэтому решили изобрести ООП и сказать, что вот оно счастье. Приверженцы этой новой парадигмы обещали возможность создания повторно используемых классов и паттернов, и это звучало заманчиво. Возможность комбинировать эти классы в многократно используемые и настраиваемые бизнес компоненты казалась Святым Граалем индустрии ПО. (с — https://habrahabr.ru/post/143620/ )

                                                    Но мы не будем говорить о наступлении кодерского коммунизма, т.к. ключевые обещания: наследование, инкапсуляцию, полиморфизм и абстракцию нифига не выполняются дальше чем сферовакуумные примеры.
                                                  • 0
                                                    Не работает? Вот же блин, а я-то не знал, и по наивности пользуюсь…
                                                    • 0
                                                      Уверены, что пользуйтесь? :-) На Smalltalk'е поднимайте здоровенные бизнес-проекты с какой-нибудь зубодробильной математикой? :-)
                                                      • 0
                                                        Smalltalk в 2017 году? Увольте.
                                                        Не думаю, что древний legacy-код на Smalltalk вообще может обладать хорошей архитектурой.
                                                        • –2
                                                          Smalltalk в 2017 году? Увольте.
                                                          Не думаю, что древний legacy-код на Smalltalk вообще может обладать хорошей архитектурой.


                                                          Ну т.е. Вы тока что расписались, шо чистое ООП — это УГ, и подтвердили мои слова :-)

                                                          Вы знайте, по возможностям ООП Java от Smalltalk отличается менее чем никак (на самом деле Жаба все же более куцая, в отличии от неё Smalltalk использует чистую ОО модель, компиляторщики вон говорят, что он так вообще — первый и единственный ООП язык, а они люди вумные — с ними лучше не спорить). Ну у C# правда есть еще мультиметоды — супер-достижение, которое перебивается паттерном Визитёр.

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

                                                          |f|
                                                          "A comment"
                                                          f := Foo new: 'AString';
                                                          


                                                          Foo f;
                                                          // A comment
                                                          f = new Foo("AString");
                                                          


                                                          Разница просто гигантская, не правда ли? :-)

                                                            initReports
                                                          	"Initialize the list of reports by reparsing the index file."
                                                          
                                                          	| parser |
                                                          	self resetReports.
                                                          	parser := IndexFileParser 
                                                                      documentBase: self documentBase 
                                                                      source: self getIndexFileStream.
                                                          	[parser atEnd]
                                                          		whileFalse: [self addReport: parser next]
                                                          


                                                              /*
                                                               * Initialize the list of reports by reparsing the index file.
                                                               */
                                                              public void initReports(String reportBase)
                                                              {
                                                                  IndexFileParser parser;
                                                                  Report report;
                                                          
                                                                  resetReports();
                                                                  parser = new IndexFileParser(getDocumentBase(), getIndexFileStream());
                                                                  while ((report = getNextReport(parser)) != null) {
                                                                      addReport(report);
                                                                  }
                                                              }
                                                          


                                                          Ну я все-таки подскажу одно значительное отличие на котором попадаются все хелоувордщики:
                                                          |i|
                                                          i := 1+(5*6).
                                                          


                                                          int i;
                                                          i=1+5*6;
                                                          


                                                          Впрочем порой он даже более читабелен:
                                                          Rectangle width: 100 height: 200
                                                          

                                                          new Rectangle(100, 200);
                                                          
                                                          • 0
                                                            Вот ничего плохого про язык Smalltalk не хотел сказать. Да и вообще, наверное, я неправ, но у меня Smalltalk ассоциируется только с легаси-кодом, а легаси-код с большим трудом ассоциируется с хорошей архитектурой. Даже если на момент разработки в 1981-м она была хорошей.
                                                            Спасибо за примеры, интересно взглянуть на синтаксис (да, разница колоссальная).
                                                            • –1
                                                              Ну как я слышал, Смоллтолк нынче больше популярен как обучающий язык программирования, т.к. все остальные ООП языки так или иначе испытывали его влияние. Но язык действительно не смог взлететь (ну по сравнению с С++, Жаба, C# и т.д.) — я хз почему, только могу предположить, мне кажется потому:
                                                              1/ Он появился слишком рано и сообщество, как и оборудование было не готово с ним работать,
                                                              2/ За этим языком не стояло никакой корпорации Зла, зато ее Жаба с ним конкурировала, я вообще про Смоллтолк узнал, когда знал уже C# (лучше бы не знал)
                                                              3/ Ну и последнее, это потому что чистое ООП оказалось не практичным и торчать в рамках одной парадигмы не тру, что С++, что Жаба, что C#, что Object Pascal — все они гибридные и мультипарадигменные языки, а в некоторых из них ООП так вообще не главное, и вероятно это не с проста.
                                                              Собственно все эти Расты, Голэнги и F# которые вообще исповедуют совершенно другие принципы появляются также не с проста. Я правда хз — взлетят ли они.

                                                              Синтаксис у Смоллтолка, конечно немного архаизмов, но в целом все тоже самое получается шо и в современных языках, некоторые вещи кажутся вполне себе даже удачными (пример с Rectangle)
                                                              • 0

                                                                Легаси это не обязательно плохой код, это всего лишь продукт, активная разработка которого прекращена. (Имхо.)

                                                                • 0
                                                                  Скорее, это продукт, который активно разрабатывали несколько десятков лет несколько десятков (или сотен) человек.
                                                                  • –1

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

                                                          • 0

                                                            OO design patterns пользуетесь? про что они вообще, замечали?

                                                            • 0
                                                              Наверняка пользовался неосознанно, изобретая самостоятельно уже известные паттерны. Я просто решаю стоящие передо мной задачи способом, который кажется наиболее простым и логичным. И я хорошо понимаю, что если делать то же самое без классов и абстраций, получится неподлдерживаемый и нерасширяемый, а главное — никому не понятный, спагетти-код.

                                                              Паттерны, очевидно, про хорошие способы решения типовых задач. Вот только на практике задачи редко бывают настолько типовыми, и без доработки напильником паттерны из той книги на задачу не натягиваются.
                                                          • +2
                                                            экземпляров класса СO2, который является наследником классов C и O

                                                            Ну если писать вот так оно конечно не будет работать. (CO2 точно не наследовать от C и O надо.)

                                                            • –1
                                                              А от чего их надо наследовать? От Господа Бога? :-)

                                                              Впрочем их вообще не надо ни откуда наследовать, Data oriented design и композиция отлично справляется, но это уже нисколько не ООП :-)
                                                              • 0
                                                                Правильно. А класс «кошка» нужно наследовать от классов «усы», «лапа», «хвост». Но ни в коем случае не от класса «животное».
                                                                При таком понимании ООП понятно, откуда у вас такие претензии…

                                                                Мартышка к старости слаба глазами стала;
                                                                А у людей она слыхала,
                                                                Что это зло еще не так большой руки:
                                                                Лишь стоит завести Очки.
                                                                Очков с полдюжины себе она достала;
                                                                Вертит Очками так и сяк:
                                                                То к темю их прижмет, то их на хвост нанижет,
                                                                То их понюхает, то их полижет;
                                                                Очки не действуют никак.
                                                                «Тьфу пропасть! — говорит она, — и тот дурак,
                                                                Кто слушает людских всех врак:
                                                                Всё про Очки лишь мне налгали;
                                                                А проку на-волос нет в них».
                                                                Мартышка тут с досады и с печали
                                                                О камень так хватила их,
                                                                Что только брызги засверкали.

                                                                К несчастью, то ж бывает у людей:
                                                                Как ни полезна вещь, — цены не зная ей,
                                                                Невежда про нее свой толк все к худу клонит;
                                                                А ежели невежда познатней,
                                                                Так он ее еще и гонит.
                                                            • 0

                                                              В иерархии классов стандартной библиотеки Java очень часто встречается многоуровневое наследование. Уровней пять могу припомнить легко. Думаю что 10 найдется.


                                                              Ну и достоверность остальных аргументов тоже слегка того… упрощаете вы. Или излишне обобщаете.


                                                              Я прекрасно помню, как выглядело скажем программирование на PL/1. Или Фортран. До ООП, в общем. И не надо далеко ходить, чтобы понять, что сегодня прикладные программисты в значительной степени занимаются тем, что собирают программы их готовых уже кусков. Не везде и не всегда — но там где это прокатывает (в первую очередь по ресурсам) — там это реально ускоряет разработку.


                                                              Так что термин "ООП не взлетело" я бы переформулировал скорее как "не смогло захватить мир". Так будет правдивее.

                                                              • –5
                                                                Вероятно просто у Оракла индусов больше чем классов, так что если кто-то что-то сломает на самом верху этой 5-и уровненной пирамидки, то они просто натравят всю эту ораву прилаживать костыли. В принципе им должно хватить всех сотрудников, шоб натравить на пирамидку из 12 ступенек наследования. А так-то большинство паттернов содержат 2-3 слоя наследования, ну было дело -пришлось как-то забацать 4 иерархии наследования (крайне специфическая задача). А все что 5+ ИМХО просто отсутствие архитектуры, клацц-клац и в продакшен, а рефакторинг для трусов, а может просто разработчики писали калькулятор для конкурса сайта http://govnokod.ru
                                                                Тем более Java наглядный пример того, что не все йогурты одинаково полезны — там вообще много чего можно и много чего есть, но это не значит что это хорошо (иногда даже об этом предупреждают) — тут даже на хабре можно много примеров найти.

                                                                Дык, на Фортране я и сейчас отлично иногда программирую — отличный язык, жалко шо бабосов стоит немерено (хотя один фиг выходит дешевле Матлаба), и при написании больших моделей выполняемых на супер-пупер-компьютерах (да и вообще для научных вычислений) выбор тут не особо велик: либо Фортран, либо Си.

                                                                Что касается того шо программисты собирают программы из готовых кусков, то эта тема не нова: злые языки поговаривают, что так и Модула умела в 70-ых года и вероятно такой подход был известен и ранее. Ну а всевозможные LAPACK, LINPACK и прочие BLAS, рожки которых торчат там где нужно выполнять операции сложнее сложения двух чисел, также были написаны на упомянутом Вами Фортране еще до того как я наверное родился (это чисто гипотеза)… не ну иногда встречаются велосипеды переписанные на Си, но без этих ваших ++ Т.е. заслуги очередной серебряной пули под названием ООП я тут не вижу.

                                                                А по поводу взлетело-невзлетело, это уже вопрос личной терминологии. И вот по-моему мнению ООП как раз таки смогло захватить весь мир: посмотрите — все мейнстримовые ЯП пытаются реализовать так или иначе ООП (мыши кололись, плакали, но продолжали есть кактус). Есть конечно небольшая группа лямбда-извращенцев, растаманов и прочих хипстеров из фанклуба Гугла, но это пока все попытки выйти из порочного круга и погоды они не делают. А вот взлететь ООП как раз таки не смогло, начиная с самого простого — любые нетривиальные абстракции текут (вроде изобретатель stackoverflow.com сказанул как-то не подумав) а дальше уже начинается… Ну или например где это ваш полиморфизм (вот только сегодня думку думал кагбэ мне написать супер-полиморфные функции, которые смогут переварить 100500 самых разных типов данных)? Мне вот нравиться как это сделано в С++ или в богомерзком Пухтоне, можно даже ромбиком наследоваться, но все кругом считают шо это не тру, поэтому давайте напридумываем всяких бесполезных интерфейсов…
                                                                • 0

                                                                  По-моему вы путаетесь в показаниях. Либо ООП "не взлетело", либо "смогло захватить мир". Либо ничего серьезно лучше нет — либо одно из двух (с).


                                                                  Да, про Оракл вы просто гоните, потому что ситуация в коде скажем Spring примерно такая же — пять и более уровней наследования даже долго искать не придется, откроете документацию — и вот оно. Не везле, далеко не везде — скажем, один класс из десятков, но такая вложенность встречается, во вполне промышленных количествах.


                                                                  И я вам даже на пальцах объясню, откуда она берется — да, один паттерн это как правило 1-2 слоя, больше вряд ли. Но это совершенно не значит, что в сложном фреймворке есть только один паттерн. Вот отсюда она и берется. А вот четыре иерархии и 10 уровней наследования — это совершенно перпендикулярные вещи.

                                                                  • +1
                                                                    В Unity3D мы все объекты наследуем от MonoBehaviour, который наследуется от Behaviour, который наследуется от Component, который наследуется от Object. 5 уровней, с которыми каждый день работаешь и ничего — никто не путается.
                                                                    • –2
                                                                      Конечно не путаются, ведь разработчики не могут добраться своими кривыми ручками до Object (внезапно), который является родителем всего и всея (внезапно). Добрые дяди уже позаботились, так что можете работать лишь с наследниками MonoBeheavor, все что выше — уже Вас не касается — это черный ящик. Правда Юнити далеко не образчик стабильности — после каждого обновления обнаруживается несовместимость со старым API, да и производительность движка оставляет желать лучшего, что кагюбэ намекает ;-)

                                                                      Но в любом случае имеем в Юнити всего 4 иерархии наследования, не 5, а именно 4 — отделяйте мух от котлет, точнее говнокод от фреймоврка, вы еще посчитайте сколько иерархий наследований в сорцах ОС и тоже их добавьте ;-)

                                                                      При этом: object — в принципе обязательный (без него никак), а component — необходимый для реализации игровой логики, т.к. Юнити это вообще не про ООП, там изначально используется компонентная модель, если что.
                                                                      • +2
                                                                        Юнити это вообще не про ООП, там изначально используется компонентная модель

                                                                        С каких пор паттерн «Компонент» перестал быть ООП? Юнити очень даже про ООП.

                                                                        который является родителем всего и всея (внезапно)

                                                                        Внезапно, я говорил о UnityEngine.Object, а не о System.Object.

                                                                        Правда Юнити далеко не образчик стабильности — после каждого обновления обнаруживается несовместимость со старым API

                                                                        Да, если они переписывают какой-то компонент, то иногда меняется API. А вы можете привести пример, как добавить новую функциональность не изменив API?

                                                                        производительность движка оставляет желать лучшего, что кагюбэ намекает ;-)

                                                                        Это универсальный игровой движок, который способен выдавать 60+ fps сложной логики с физикой и рендером на слабых мобильных устройствах. О каких проблемах с производительностью вы говорите? Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.

                                                                        могут добраться своими кривыми ручками

                                                                        Так проблема в количестве иерархии, или в том, что «могут добраться»? Ибо если в том, что «могут добраться», то и с 1 уровнем можно добраться. Или вы думаете, что если использовать композицию вместо наследования добраться внезапно становится нельзя?
                                                                        • –3
                                                                          С каких пор паттерн «Компонент» перестал быть ООП? Юнити очень даже про ООП.

                                                                          С таких, что компонентно-ориентированное программирование это независимая парадигма программирования, которая была придумана Виртом для решения проблем внезапно возникших у ООП, и реализованная в языке, который является ОО менее чем никак
                                                                          https://ru.wikipedia.org/wiki/Оберон_(язык_программирования)
                                                                          Оттуда КОП ушло в ныне мейнстримовые языки и стало их частью, т.к. действительно, в большинстве случаев композиция предпочтительнее наследования. Тут же на хабре, уже ни раз обсуждали разницу между КОП и ООП.

                                                                          Да, если они переписывают какой-то компонент, то иногда меняется API. А вы можете привести пример, как добавить новую функциональность не изменив API


                                                                          Вот только недавно это на работе обсуждали, правда в контексте Python 2 RIP: программа написанная на С++ в 1989 году, компилится в 2017, программа написанная на C# под .NET 1.0 в 2002..2003 годах (язык был стандартизирован по ISO в 2003 вроде бы, а бета-версию вроде как опубликовали эдак в году 2001), точно также внезапно скомпилится и заработает в 2017 году. Хотя там тоже бывали костыли, например, до появления Джнерик-типов в .NET 2.0, в общем обратная совместимость худо-бедно выполняется. Хз, чего там у Жабы — не занимался такой глубокой интроспекцией в ней, но думаю худо-бедно норм.

                                                                          Однако в большинстве своем все не так безоблачно.

                                                                          Так проблема в количестве иерархии, или в том, что «могут добраться»? Ибо если в том, что «могут добраться», то и с 1 уровнем можно добраться. Или вы думаете, что если использовать композицию вместо наследования добраться внезапно становится нельзя?

                                                                          Ну потому что, то что зарыто внутри фреймворка, разработчика уже не касается, т.к. отнаследовавшись один раз для него вот энта проблема:
                                                                          https://ru.wikipedia.org/wiki/Хрупкий_базовый_класс
                                                                          еще не актуальна, все что внутри фреймворка — это уже головная боль его создателей. К счастью, у них индусов (в штате, на аутсорсе, на аутстафее) вероятно больше чем классов а также есть вумные архитекторы-надсмоторщики с кнутами, так что они могут себе позволить сопровождать, поддерживать и развивать ПО где объемы наследования очень-очень велики.
                                                                          Так что в условиях неограниченных ресурсов (как индусо-часы, так и ресурсы вычислительных машин) — это работает. Но у большинства ресурсы ограниченные — и тут выясняется, что сложность программы (как разработки, так и цикломатическая сложность) растет экспоненциально от глубины наследования. В тоже время какой-то учитель математики по фамилии Степанов в 3.5 написал STL, которая уже больше 20 лет успешно используется и включена в стандарт. Заранее предупрежу, что STL это тоже не про ООП, а Степановтак вообще один из самых ярых критиков ОО-подхода.

                                                                          Это универсальный игровой движок, который способен выдавать 60+ fps сложной логики с физикой и рендером на слабых мобильных устройствах.

                                                                          Слабое мобильное устройство — это Нокиа 1100, еще космические спутники (там до сих пор летают на 51-ой архитектуре и килобайтами памяти). А современные говносмартфоны и говнопланшеты по вычислительной мощности круче домашних писюков начала 2000-ых. К слову сказать Unreal и Quake были изначально написаны на чистом Си еще в 90-ых
                                                                          Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.

                                                                          Вы просто всего 2 движка знайте
                                                                          … способен выдавать 60+ fps сложной логики с физикой....

                                                                          Уравнения Максвелла тожее умеет решать, или кварк-глюонную плазму смоделирует? В физике там ничего особенного: коллизии, 2-ой закон Ньютона, уравнение движение и т.п. — примерно 1-ый курс… потом студенты в рамках лабораторных работ/курсовых сами пишут куда более сложные физические модели.
                                                                          способен выдавать 60+ fps

                                                                          Если там на сцене живет 3.5 МоноБихеавор, то да, а так:
                                                                          https://forum.unity3d.com/threads/general-performance-optimization-tips-for-unity.386338/
                                                                          В общем удже давно известно, что производительность и Юнити ТрыДэ это несовместимые понятия. Но Unity3D не за это любят, а за
                                                                          Это универсальный игровой движок

                                                                          Но за все надо платить https://ru.wikipedia.org/wiki/Технический_долг

                                                                          Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.

                                                                          Обычно там внутри что-то типа такого:
                                                                          https://www.youtube.com/watch?v=rX0ItVEVjHc&t=270s
                                                                          Что тоже не ООП. У меня вон тоже, когда говнокодю на C# начинают плодиться всякие unsafe:
                                                                          public unsafe static Matrix UnsafeMultiplication(Matrix A, Matrix B)
                                                                             {
                                                                                 int h = A.Height;
                                                                                 int w = B.Width;
                                                                                 int l = A.Width;
                                                                                 Matrix resultMatrix = new Matrix(h, w);
                                                                                 unsafe
                                                                                 {
                                                                                     fixed (double* pM = resultMatrix._matrix, pA = A._matrix, pB = B._matrix)
                                                                                     {
                                                                                         int indexA, indexB;
                                                                                         for (int i = 0; i < h; i++)
                                                                                         {
                                                                                             indexA = i * l;
                                                                                             for (int j = 0; j < w; j++)
                                                                                             {
                                                                                                 indexB = j;
                                                                                                 double result = 0;
                                                                                                 for (int k = 0; k < l; k++, indexB += w)
                                                                                                 {
                                                                                                     result += pA[indexA + k] * pB[indexB];
                                                                                                 }
                                                                                                 pM[i * w + j] = result;
                                                                                             }
                                                                                         }
                                                                                     }
                                                                                 }
                                                                                 return resultMatrix;
                                                                             }
                                                                          


                                                                          Это примерно раз в 10 быстрее чем вот такое:
                                                                           public static Matrix NaiveMultiplication(Matrix A, Matrix B)
                                                                              {
                                                                                  Matrix resultMatrix = new Matrix(A.Height, B.Width);
                                                                                  for (int i = 0; i < resultMatrix.Height; i++)
                                                                                  {
                                                                                      for (int j = 0; j < resultMatrix.Width; j++)
                                                                                      {
                                                                                          resultMatrix[i, j] = 0;
                                                                                          for (int k = 0; k < A.Width; k++)
                                                                                          {
                                                                                              resultMatrix[i, j] += A[i, k] * B[k, j];
                                                                                          }
                                                                                      }
                                                                                  }
                                                                                  return resultMatrix;
                                                                              }
                                                                          

                                                                          Правда unsafe это вообще не про .NET, а так — грязный трюк (да, мыши кололись, плакали, но продолжали жрать кактус). И ООП тут встречается в гомеопатических количествах, лишь при описании собственного класса Matrix. Впрочем к версии 4.5 .NET все же узнал, шо есть такая офигенная штука как SIMD (Intel Pentium MMX, 1997 год, 16кБ L1, 166 МГц), так что жить стало лучше, жить стало веселее.

                                                                          Потом да, потом это все будет обернуто со стороны клиента уже в читабильный ООП-код
                                                                    • 0
                                                                      По-моему вы путаетесь в показаниях. Либо ООП «не взлетело», либо «смогло захватить мир». Либо ничего серьезно лучше нет — либо одно из двух (с).

                                                                      Открою тайну — это два разных понятия, если не догадались. Что значит «не взлетело» — я пояснил, что значит «захватило мир» — я тоже пояснил, так что Ваше непонимание вызывает у меня недоумение 0_0

                                                                      Да, про Оракл вы просто гоните

                                                                      Т.е. Вы считайте, что у них классов все же больше чем индусов? Ну допустим.

                                                                      Не везле, далеко не везде — скажем, один класс из десятков, но такая вложенность встречается, во вполне промышленных количествах.

                                                                      Так не везде или все же в промышленных масштабах? Определитесь уже. Вы похоже пытайтесь выдать исключительную ситуацию за рядовую, при этом мой рекорд в 20+ иерархий наследования так и не побили. При этом я могу дать подсказку (по крайней мере для .NET), где искать большую вложенность — обычно в компонентах UI любят наплодить дофига наследников (но правда 20+ Вы там все равно не найдете), на то даже есть свои причины

                                                                      • 0
                                                                        не совсем про наследование, но про стектрейсы в JavaEE
                                                                        • –2
                                                                          Странно шо Вы не выложили снимок всего дампа памяти. Вы просто путайте стэк вызовов с наследованием. Можно и в Сях без всякого наследования получить не меньше, а если еще и функция рекурсивная…

                                                                          Другое дело, шо как форма отражения цикломатической сложности, снимок стэка вызовов должен отразить её повышение при использовании наследования
                                                                          • 0

                                                                            Не бойтесь, не путаю. Просто вы не осилили прочитать название спойлера.

                                                                            • –1
                                                                              Нет, просто я не очень понимаю:
                                                                              1) Какое это имеет отношение к сабжу (если забыли, то это Go)
                                                                              2) Как это имеет отношение к срачу про наследование
                                                                              То что Вы осилили Java.lang.Thread.getStackTrace() меня, конечно, несказанно радует, но не обязательно об этом на каждом углу кричать? А то вдруг набижит бородатый погромист и выложит свой дамп :-)
                                                            • –2
                                                              Вброс засчитан… осталось только выяснить, шо такое Rust и использует ли его хоть кто-нибудь, кроме Мозиллы для задач сложнее ХеллоуВорлда. Я вот только про игру с таким названием слышал, но сомневаюсь, что это хоть как-то связано с этим языком, его популярностью и применимостью…
                                                              • +2
                                                                Я вот только про игру с таким названием слышал

                                                                Показательно, только не в том смысле, что ты думаешь.

                                                                • –3
                                                                  Показательно это то что Rust в продакшене не используется от слова «совсем» (ну допустим «почти совсем»), по крайней мере за пределами Мозилы и 3.5 фанбоев. В то время как на сабже написан тот же Докер, а пользуются всякие Атлласианы, Адобы, АйБиЭмы и прочие Дропбоксы, даже китайцы на нем пишут — вот это показательно.

                                                                  Так шо я даже хз, представляет ли слово Rust хоть какой-нибудь интерес за пределами одноименной игры :-) Вероятно нет — все его хвалят, но никто замуж не берет, пичалька :-)
                                                                  • +3
                                                                    и прочие Дропбоксы

                                                                    Действительно

                                                                    • –2
                                                                      Странно, не хватает еще скриншотов с IBM, Atlassian, Adobe, ну и т.д. по списку, пичалька, ну шо Вы ей Б-г прям как маленький — ищите и обрящите: https://github.com/golang/go/wiki/GoUsers
                                                                      Ссылку на rust-friends для сравнения судя по всему сами в состоянии найти ;-)
                                                                      • 0

                                                                        Ещё даже пары лет не прошло как раст релизнулся, просто не успели же ещё ничего накодить, это вам не фигак-фигак и в продакшен, ну шо Вы ей Б-г прям как маленький :)

                                                                        • 0
                                                                          Да, первый релиз спустя 5+ лет существования языка это конечно достижение :-)
                                                                          Помниться мне первая версия C# появилась одновременно с появлением самого языка в 2002 году и она уже была стабильна, через год — в 2003 году — язык был стандартизирован в ISO, а в 2005 вышла уже 2.0 в которой он уже предстал полностью сформированный языком (дальше пошли свистели и переделки, да синтаксический сахар для индусов). И да, никаких проблем с обратной совместимостью (это правда не значит что хорошо использовать ArrayList!) За 15 лет существования.

                                                                          Аналогично можно сказать и за Голэнг — он причем ровесник Раста, но первая версия релизнулась еще 5 лет назад :-)
                                                                          • +2

                                                                            Ну так результат наглядно виден: Rust намного более тщательно проработан чем Go или C# :D

                                                                          • +2
                                                                            Да, первый релиз спустя 5+ лет существования языка это конечно достижение :-)

                                                                            Учитывая постоянные передёргивания, на нормальный ответ не надёюсь, но всё-таки. Про C# пишут, что в январе 1999 была уже сформирована команда, которая занималась языком. Причём мне что-то подсказывает, что видение конечного результата было уже сформировано. Раст же начинался как проект одного человека, язык прошёл через множество экспериментов до того как окончательно оформился. Я уж не говорю о том, что ресурсы мозиллы и майкрософта не сопоставимы.


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

                                                                            • 0
                                                                              Ну вообще я об этом и говорил.

                                                                              Сообществу .NET был предоставлен сразу рабочим (ну почти, где-то за год подписчики msdn получили бета-версию .NET, меня в их числе естественно тогда еще не было — я с говнокодингом на нем познакомился лишь в 2005 году), после чего он очень шустро был стандартизирован, и тут же пошел в продакшен и начал набирать популярность. Java конечно он не переплюнул, но вполне с ней конкурирует и даже вопреки политике Microsoft стал кросс-платформенным языком, да и Java куда старее и к моменту появления C# у неё уже было устойчивое сообщество погромистов. И всю свою публичную историю существования этот язык идет по пути расширения и добавления новых свистелок и переделок.

                                                                              И это важно, т.к. предыстория появления языка может быть очень долгой и богатой — вообще C# можно считать потомком Delphi, создавали их одни и те же люди, вообще папа Delphi и C# — создатель компилятор Turbo Pascal, так что при желании можно отследить историю языка начиная с даты рождения Вирта. А еще у Корпорации Добра была своя Жаба.
                                                                              Но вот история конкретно языка начинается все же с его обнародования и начала использования — официальная дата его рождения: 2000-ый год (я так понимаю его тогда анонсировали), а в 2002..2003 пришла Visual Studio.NET где он был. Так что история использования языка и платформы .NET начинается с 2002 года. Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).

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

                                                                              Об этом я собственно и толкую. С видением проект у создателей Раста явно какие-то проблемы (но сейчас вроде обещают, что все стало норм), а вот у создателей его ровесника (и вероятно конкурента) — Golang, который тоже кстати показали людям до того как выкатился в релиз, с этим дело обстоит вероятно несколько лучше. С видением всяких Java и прочьих дотНетов вероятно вообще все замечательно.

                                                                              Я уж не говорю о том, что ресурсы мозиллы и майкрософта не сопоставимы.

                                                                              Об этом я тоже где-то здесь уже писал (Оракл и его тысячи и тысячи индусов). Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL. А еще вот всопмнился язык D — его тоже одиночки поднимали. Не сказать что он убер-популярный, скорее совсем непопулярный, но кое-кто им пользуется, я даже кусок живого проекта на нем видел.
                                                                              • +1
                                                                                Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).

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


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


                                                                                С видением проект у создателей Раста явно какие-то проблемы

                                                                                Не очень согласен, но безотносительно этого: как по мне, лучше пусть будет много экспериментов до релиза, чем потом будет язык из стороны в сторону бросать. Интересно было бы послушать если ли какие-то претензии к языку в этом плане после версии 1.0.


                                                                                Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL.

                                                                                Ну положим они больше пруф оф концепт делали, чем конечную (современную) реализацию.


                                                                                А еще вот всопмнился язык D — его тоже одиночки поднимали.

                                                                                Вот мне кажется, что все эти метания с D1/D2 и фобос/деймос, в немалой степени, тому причина. И если бы они подольше подержали язык в "дорелизном" состоянии, то этого, возможно, удалось бы избежать.

                                                                        • +3

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

                                                                          • –3
                                                                            Если внимательно прочитайте, то речь шла о том, что за 7 лет существования Раста им пользуется только Мозилла, да 3.5 фанбоев — увы, но такова жестокая реальность :)
                                                                            Может еще лет через 7, когда выйдет очередная «теперь точно стабильная версия» на нем и начнут что-нибудь выпиливать интересного :-)
                                                                            • +2

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


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

                                                                              А это к чему? С версии 1.0 совместимость вполне обеспечивается. Есть конкретные претензии или это просто сотрясание воздуха?

                                                                      • +2
                                                                        Показательно это то что Rust в продакшене не используется от слова «совсем»

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

                                                                        • –2
                                                                          Ну также можно запилить проект на Брейнфаке, и это наверное будет очень показательно…
                                                                          Проект на Растет и у меня был, но пока не наберется критической массы таких проектов, говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво. Голэнг уже успешен, Растт — нет, он даже в 20-ку языков по версии IEEE и TIOBE не входит — гордо тусуется в компании всяких узкоспециализированных Верилогов (но им не стыдно, ибо эртээльщики народ особый и их мало), а вот Scratch входит :-)
                                                                          • +1
                                                                            говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво

                                                                            А кто говорит о суперуспешности? Изначальное утверждение звучало совсем не так. Я просто хочу сказать, что на расте работу найти реально. Да, её (очень) мало, но тот самый "продакшен" имеется.


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

                                                                            • 0
                                                                              Ну тут гипербола. Просто оперировать «вот мы щас пилим проект на Расте и нам этого достаточно» — выглядит не совсем корректно. Я вот как-то запилил целый Asteroids на F# (самом деле XNA+C#+F#), но это не делает его языком выбора, не смотря на все его достоинства и няшность. И естественно я никому его не навязываю (не смотря на его няшность). И даже кое-что на Расте заговнокодил (есть у меня подозрение, не для того, для чего его обычно используют), что и его не превращает в язык выбора (тем более F# няшнее)…
                                                                              А еще у меня в универе был знакомый который на протяжении нескольких лет запилил на асме игровой движок (ТрыДэ!) — что, конечно, круто, но не понятно, нафига это. Ну в общем хвалиться не прикольно.

                                                                              Впрочем у Раста в этом плане все же дела лучше — хз на сколько, но вот про вакансии Java-программистов с опытом разработки в Rust и Golang 0_0 я уже слышал, ну и по крайней мере его хотя бы Samsung начал активно педалить. Но все равно пока это «самый любимый язык программирования на котором никто не кодит» https://stackoverflow.com/insights/survey/2016#technology-most-loved-dreaded-and-wanted
                                                                              а самымой популярной технологией по-прежнему остается богомерзкий ЖабаСкрипт https://stackoverflow.com/insights/survey/2016#technology-most-popular-technologies

                                                                              Хз, может он и через пару лет выбъется в топ-20 используемых языков общего назначения (и холивары Go vs Rust станут еще более острее, что не может не огорчать)
                                                                              • 0
                                                                                но это не делает его языком выбора, не смотря на все его достоинства и няшность.

                                                                                Почему? Если в каком-то определённом случае достоинства перевешивают недостатки, то как по мне, язык вполне можно рассматривать


                                                                                Ну в общем хвалиться не прикольно.

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

                                                                          • +1

                                                                            Мы тоже пилим небольшой проектик на rust, который пойдёт в open source (под GPLv3+, т. к. samba, которая используется внизу, под GPL). Когда запилим пока неясно, т. к. висят более приоритетные задачи.


                                                                            Есть ещё одна библиотека, которую я планирую нафигачить сам с перспективой использование на работе. Только там сначала надо написать dissector для wireshark'а и отреверсить протокол xD

                                                                            • –3
                                                                              Ок, с прожектерством разобрались, теперь ждем первого человека, кто пилил-пили и все же таки запил свой проект на Rust ;-)
                                                                              • +2

                                                                                Вы не осилили в поиск по гитхабу или как?

                                                                                • –1
                                                                                  Ок Гугл, покажи мне Nelder-Mead:
                                                                                  Languages
                                                                                  14 C#
                                                                                  13 C++
                                                                                  11 Python
                                                                                  4 C
                                                                                  2 JavaScript
                                                                                  2 Jupyter Notebook
                                                                                  2 Matlab
                                                                                  1 Go
                                                                                  1 Java
                                                                                  1 Julia

                                                                                  Хм… чего-то не хватает. Ок, Гугл, нука покажи nonlinear optimization:
                                                                                  Languages
                                                                                  26 Matlab
                                                                                  17 C++
                                                                                  14 C
                                                                                  11 Python
                                                                                  6 Java
                                                                                  6 R
                                                                                  5 Julia
                                                                                  4 Fortran
                                                                                  4 Jupyter Notebook
                                                                                  3 Haskell

                                                                                  Хм… Хаскель — есть, C# — есть, Фортран — есть, Джулия — есть, Пухтон тоже есть, как и R, C/C++, C#, Java, внезапно даже сбаж [если не забыли, то говорили о Go] есть.

                                                                                  Хм, что я делаю не так? Ах да, точно, можно же было бы посмотреть сводную статистику, например тут https://octoverse.github.com/

                                                                                  Понимайте, мне нет нужды целенаправленно выискивать сорцы языка Мозиллы и прожектеров, т.к. есть 20 десятка наиболее везде-используемых языков + нишевые специализированные языки (типа Verilog или VHDL), на половине из которых я худо-бедно говнокодю. А еще на них говнокодят миллионы других людей, а еще больше пользуются их продуктами.

                                                                                  А вот по логике веще, что-то выискивать и показывать должны фанбои Раста. В контексте холивара я даже привел пример Докера и список компаний использующих Golang, в ответ: какие-то скриншоты и обещания: «вот мы на нем говнокодим, скоро-скоро будет релиз, и вы все офигейте».

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

                                                                                  Может быть, когда-нибудь, когда на Марсе начнут сажать яблони (а может даже и завтра), к Rust проснется вторая волна интереса и на нем начнут массово писать, тогда да, тогда Rust будет интересен, сейчас куда более интересен тот же COBOL, например.
                                                                              • 0

                                                                                Тоже похвастаться хочется, но сдержусь до того момента как проект официально анонсируют и когда можно будет ссылку на гитхаб дать. (:

                                                                      • –1
                                                                        Rust очень поздно заморозил синтаксис.
                                                                        • +1

                                                                          И что?

                                                                          • 0
                                                                            Думаю, если бы они заморозили синтаксис раньше, они смогли бы получить большую популярность. А сейчас часть пользователей успела убежать в Go т.к. Rust позже заморозился.
                                                                            • –4

                                                                              Go нагибает Rust вовсе не из-за что кто-то там не заморозился. Бизнес и инженеры выбирают Go потому, что это язык для жизни. А Rust отправляют в помойку потому, что это оверинженеринг, состоящий сплошь из неудобных в использовании костылей (которые почему-то называют zero-cost abstractions, забывая про ментальный cost) во имя memory safety и data race safety.

                                                                              • +1
                                                                                Бизнес и инженеры выбирают Go потому, что это язык для жизни.

                                                                                Не фраза, а плейсхолдер.
                                                                                Если уж на то пошло, то лучший язык для жизни — это английский.
                                                                              • 0

                                                                                Заморозили бы раньше — было бы больше кривых моментов, так что не факт, что была бы выгода. Вон макросы, как по мне, лучше бы ещё придержали, но сделали их более удобными. С другой стороны, без них многое было бы менее удобно.


                                                                                Ну и не думаю, что раст и го прямые конкуренты. Кое в чём они, конечно, близки, но местами разница очень значительна: и в деталях реализации и в "философии".

                                                                                • 0
                                                                                  Согласен, разница у них есть. Не было бы смысла разрабатывать одинаковые языки.
                                                                                • +1

                                                                                  Которые вернутся — молодцы, которые нет — так им и надо.

                                                                          • +23

                                                                            Как круто, автор наконец изобрел универсальную объективную метрику "красоты и естественности кода"! Ну вот теперь заживем, теперь-то узнаем, кто говнокодит, а кто рефакторингом занимается! Интересно, в чем она измеряется, в сусликах/1k LOC, или еще как-то? Хотелось бы так же узнать точные значения для js/perl/python/ruby и прочих неудачников из левого нижнего угла, чтоб выяснить раз и навсегда, кто наименее отстойный.

                                                                            • 0
                                                                              Меня особо js интересует. По каким таким критериям он попал в список красивых и естественных?
                                                                              • 0
                                                                                Меня больше интересует Perl, на котором можно писать стихи
                                                                                • 0

                                                                                  Вот это щас обидно было!


                                                                                  А вы вообще заметили, в каком месте он находится на графике?

                                                                                  • 0
                                                                                    Да, графики перепутал, но удобным и читаемым я бы его тоже не назвал бы.
                                                                                    • 0
                                                                                      neit_kas
                                                                                      но удобным и читаемым я бы его тоже не назвал бы.

                                                                                      К примеру, отобразите на другом языке такое лаконичное в JS:
                                                                                      let sobaka = { klichka: «Jim», poroda: «dog», say() {console.log( this.klichka + ":gav" )}};
                                                                                      sobaka.say();
                                                                                      • +5
                                                                                        Замечательно! И обфускации никакой не надо: код самообфусцирующийся.
                                                                                        • 0
                                                                                          К примеру, отобразите на другом языке такое лаконичное в JS:

                                                                                          C#. Никто в здравом уме, конечно, такое делать не будет:

                                                                                          var jim = new {
                                                                                            Name  = "Jim",
                                                                                            Breed = "Dog"
                                                                                          }; 
                                                                                                      
                                                                                          Console.WriteLine( jim.Name + ":woof" );
                                                                                          
                                                                                          • +1

                                                                                            F#


                                                                                            let jim =
                                                                                              {
                                                                                                name = "Jim";
                                                                                                breed = "unknown";
                                                                                                say = fun self -> printfn "%s: woof!" self.name;
                                                                                              }

                                                                                            тип, правда, самому придется написать.

                                                                                            • +2
                                                                                              Scala.
                                                                                              scalafiddle.io
                                                                                              val sobaka = new {
                                                                                                val klichka = "Jim"
                                                                                                val poroda = "dog"
                                                                                                def say() = println(klichka + ":gav")
                                                                                              }
                                                                                              
                                                                                              sobaka.say()
                                                                                              

                                                                                              • +3
                                                                                                Тут люди думаю достаточно привели не менее лаконичных примеров. Сам на плюсах в основном, а с его местом в том графике я вполне согласен, так что вариант от туда приводить не буду. А так, что лично мне не нравится в читаемости js:
                                                                                                1) Полное отсутствие типизации. Меня это дико напрягает. Это удобно в использовании, но в оочевидности.
                                                                                                2) Когда this может оказаться совсем не this.
                                                                                                3) В реальном коде в нём часто куча артефактов от html. Сам html убирается всякими библиотеками, а вот классы несколько мешаются.
                                                                                                4) ES6 явно позитивно не сказался на его читаемости.

                                                                                                Я бы его в самый низ графика ясное дело не засунул, но и в самую верхушку тоже.
                                                                                                • –5
                                                                                                  neit_kas
                                                                                                  Тут люди думаю достаточно привели не менее лаконичных примеров.


                                                                                                  Разберём эти примеры на лаконичность:

                                                                                                  TheShock C#.

                                                                                                  var jim = new {
                                                                                                    Name  = "Jim",
                                                                                                    Breed = "Dog"
                                                                                                  }; 
                                                                                                              
                                                                                                  Console.WriteLine( jim.Name + ":woof" );
                                                                                                  


                                                                                                  Хм, зачем тут new? — И это же структура, а не объект. Не так ли?
                                                                                                  Поэтому вам и пришлось использовать внешнюю функцию, которая никак не связана со структурой jim
                                                                                                  Печально.

                                                                                                  Sirikid F#

                                                                                                  type Dog =
                                                                                                    {
                                                                                                      name : string;
                                                                                                      breed : string;
                                                                                                      say : Dog -> unit;
                                                                                                    }
                                                                                                      member self.callSay () = self.say self
                                                                                                   
                                                                                                  let jim =
                                                                                                    {
                                                                                                      name = "Jim";
                                                                                                      breed = "unknown";
                                                                                                      say = fun self -> printfn "%s: woof!" self.name;
                                                                                                    }
                                                                                                   
                                                                                                  jim.callSay ()
                                                                                                  


                                                                                                  Хм, это лаконично?
                                                                                                  Я не понял — а как jim связан у вас с «type Dog»?

                                                                                                  Эта строка — «member self.callSay () = self.say self» — очевидно крутая, и имеет наверное какой-то смысл, но явно не лаконичный.

                                                                                                  «say = fun self -> printfn „%s: woof!“ self.name;» — тут похоже «fun» от слово «function», но не помешало бы убрать его вообще, заменив на ().

                                                                                                  %s глазами нужно сопоставить с self.name? Это конечно было давно придумано. Привыкнуть можно. Но и глаза ломаются, если много параметров надо в шаблон подставлять. Имхо.

                                                                                                  Ну, ладно, я бы по лаконичности поставил этот код не на первое место.

                                                                                                  senia Scala.

                                                                                                  val sobaka = new {
                                                                                                    val klichka = "Jim"
                                                                                                    val poroda = "dog"
                                                                                                    def say() = println(klichka + ":gav")
                                                                                                  }
                                                                                                  
                                                                                                  sobaka.say()
                                                                                                  
                                                                                                  


                                                                                                  Scala — это здорово. Особенно отсутствие запятых, их похоже заменяют слова «val» и «def»
                                                                                                  А «println(klichka + »:gav")" — без лишних (обрамляющих скобок в данном случае) — это лаконично.
                                                                                                  Так и не использование «this» в строке:
                                                                                                   def say() = println(klichka + ":gav")
                                                                                                  

                                                                                                  Это впечатляет, однозначно.

                                                                                                  Слово new конечно не даёт лаконичности, но ладно. Терпимо. Имхо.

                                                                                                  neit_kas
                                                                                                  Что лично мне не нравится в читаемости js:
                                                                                                  1) Полное отсутствие типизации. Меня это дико напрягает. Это удобно в использовании, но в оочевидности.

                                                                                                  Типизация — это признак "бюрократичности" языка.
                                                                                                  Конечно, она помогает.
                                                                                                  Но иногда её хочется не использовать. В JS её можно применить (Flow, TypeScript — ну, это конечно, не так бронебойно как в иных языках) или нет. Выбор есть.

                                                                                                  neit_kas
                                                                                                  2) Когда this может оказаться совсем не this.

                                                                                                  Вот тут не поспоришь. Кое-что меняется — стрелочные функции. Но всё же тут надо думать, это верно.

                                                                                                  neit_kas
                                                                                                  4) ES6 явно позитивно не сказался на его читаемости.


                                                                                                  Но лаконичности добавилось. Это несомненно. Имхо, конечно, имхо (С)

                                                                                                  P.S. и ещё пример на лаконичность (JavaScript):

                                                                                                  var klichka = 'Jim';
                                                                                                  var poroda = 'dog';
                                                                                                  
                                                                                                  var sobaka = { klichka, poroda, say(){console.log(`${this.klichka} : gav` )}};
                                                                                                  
                                                                                                  sobaka.say();
                                                                                                  

                                                                                                  В коде создаётся объект:
                                                                                                  Object {klichka: "Jim", poroda: "dog", say: function}
                                                                                                  

                                                                                                  Ну, разве это не лаконичное создание объектного литерала?
                                                                                                  (А как же лаконично выглядит сейчас выражение без "+" в console.log метода say()!)

                                                                                                  • 0

                                                                                                    Синтаксическим оверхедом повеяло...

                                                                                                • +3
                                                                                                  К примеру, отобразите на другом языке такое лаконичное в JS:

                                                                                                  Видите ли, ваша задача в такой постановке вопроса не имеет смысла. Даже когда я пишу на JS — я не пишу такой плохой код, ибо пускай он лаконичный — он:
                                                                                                  1. Не имеет смысла в таком виде (например, зачем тут вообще использовать метод?)
                                                                                                  2. Не расширяется.

                                                                                                  Так что на любом языке задачу в такой постановке можно записать очень кратко:
                                                                                                  Console.WriteLine("Jim:gav")
                                                                                                  


                                                                                                  Вопрос обычно к реюзу кода, а тут что в JS, что в C# код будет приблизительно одинаковый и все более выравниваться с увеличением кодобазы.
                                                                                                  • –4
                                                                                                    TheShock
                                                                                                    Так что на любом языке задачу в такой постановке можно записать очень кратко:


                                                                                                    Я привел пример лаконичного создание объектного литерала и вызова у него метода.

                                                                                                    Я это выше выделил и не раз.

                                                                                                    Остальные либо не привели ничего такого, либо, как вы, не поняли, что же нужно привести в пример лаконичного.

                                                                                                    Ну, а что касается С# — возможно это и лаконичный язык, но пока это не видно мне, но зачем его вообще придумали я даже не знаю (он же "улучшатель" Java, не более того).

                                                                                                    • +1
                                                                                                      Понимаете ли, вы ставите ненужное в программировании условие.
                                                                                                      Вот давайте я вам приведу пример шоковицкого (от моего никнейма) куска кода на C#:

                                                                                                      public class Progression
                                                                                                      {
                                                                                                          public readonly int Time;
                                                                                                      
                                                                                                          public int Progress { get; private set; }
                                                                                                      
                                                                                                          public bool IsReady {
                                                                                                              get { return Progress >= Time; }
                                                                                                          }
                                                                                                      
                                                                                                          public Progression ()
                                                                                                          {
                                                                                                              Progression(0);
                                                                                                          }
                                                                                                      
                                                                                                          public Progression (int time)
                                                                                                          {
                                                                                                              Time = time;
                                                                                                              Progress = 0;
                                                                                                          }
                                                                                                      }
                                                                                                      


                                                                                                      Видите, как шоковицки у меня получилось? Просто 10 из 10. Попробуйте повторить на JS! И как только у вас на JS получится так же шоковицки, то я обязательно вам напишу лаконично все, что захотите.

                                                                                                      Конечно, данная метрика никакого отношения к практическому написанию кода не имеет. Как и ваша, впрочем.
                                                                                                      • 0
                                                                                                        Создание объекта без формализации его контракта — занятие в общем случае бесполезное.
                                                                                                        И в JS для этого раньше использовались методы-конструкторы. Сейчас появился синтаксис с классами, а ещё лучше — полноценная типизация с Flow.
                                                                                                        В этом отношении мой пример на Scala был призван продемонстрировать то, что на других языках так не пишут не потому, что так не получится, а потому, что бесполезно. И лаконичными делают на этих языках полезные конструкции. Но иногда, как на Scala, и бесполезные конструкции случайно оказываются лаконичными. Не стоит из этого делать далеко идущие выводы.
                                                                                                        • –4
                                                                                                          senia >
                                                                                                          В этом отношении мой пример на Scala был призван продемонстрировать то, что на других языках так не пишут не потому, что так не получится, а потому, что бесполезно. И лаконичными делают на этих языках полезные конструкции

                                                                                                          TheShock
                                                                                                          Конечно, данная метрика никакого отношения к практическому написанию кода не имеет. Как и ваша, впрочем.

                                                                                                          «Сражение в Фермопилах было выиграно персидским царём Ксерксом, но… известен лаконичный ответ царя Леонида на предложение сложить оружие в обмен на жизнь: «Придите и возьмите»» (Википедия)

                                                                                                          Так что полезность (практичность) и лаконичность — это перпендикулярные понятия. (С)

                                                                                                          TheShock
                                                                                                          Видите, как шоковицки у меня получилось? Просто 10 из 10. Попробуйте повторить на JS!

                                                                                                          Повторить что? Ваш совсем не лаконичный код что делает то?

                                                                                                          P.S.
                                                                                                          Пример на JS лаконичной, но по мнению автора этих строк — «сонной сортировки» — "sleep sort")
                                                                                                          var numbers = [7, 1, 77, 15, 145, 9, 5];
                                                                                                          numbers.forEach( num => {
                                                                                                              setTimeout(() => {console.log (num)} , num);
                                                                                                          });
                                                                                                          
                                                                                                          

                                                                                                          Разве это не супер! ;-)
                                                                                                          • +4
                                                                                                            Нет, не супер. Все эти дрочерства на призрачные и в общем случае не самые полезные метрики типа «лаконичность» и «смотри как я могу» обычно заканчиваются трудночитаемым и трудноподдерживаемым кодом.
                                                                                                            • +4

                                                                                                              Мне кажется, вы лаконичность с краткостью спутали. Лаконичный ответ Леонида содержит много смысла в малом количестве слов. А ваш "лаконичный" код содержит только глупую шутку в стиле "смотри как я могу".

                                                                                                              • –1
                                                                                                                Azoh
                                                                                                                Мне кажется, вы лаконичность с краткостью спутали. Лаконичный ответ Леонида содержит много смысла в малом количестве слов. А ваш «лаконичный» код содержит только глупую шутку в стиле «смотри как я могу».

                                                                                                                Сами понимаете, что отличие пошлого(или глупого) анекдота от остроумного — оно не в количестве текста анекдота, а в голове внимающего, хотя всё же «Скверный анекдот» — это рассказ.

                                                                                                                Что касается JS — то он и был фактически создан для лаконичного написания кода, выполняющегося в броузере, в отличии от развесистого синтаксиса Java и прочих подобных языков.

                                                                                                                codemax
                                                                                                                Нет, н