*** ВНИМАНИЕ: Блог переехал на другой адрес - demin.ws ***

четверг, 19 августа 2010 г.

Роб Пайк критикует С++ и Java

Из этого небольшого видео, где автор и идеолог языка GO Роб Пайк делится своим недовольством языками С++ и Java, я вынес для себя классную мысль: в С++ и Java очень "важно" знать и использовать паттерны (какой уважающий себя программист на этих языках не знает хотя бы одного паттерна?), но наличие паттернов (а особенно их обилие) - это отрицательное свойство! То есть знание языка как такового - это еще полдела, так как затем надо еще и знать "правильные" паттерны.

Вобщем, я становлюсь фанатом этого дядьки.

Update: А комментарий с семью различными типами умных указателей в Бусте - это вообще шедевр.

21 комментарий:

  1. Как будто нельзя те же шаблоны использовать в языках с динамической типизацией и в Go. Я бы сказал так: не все шаблоны одинаково полезны. Но что можно предложить взамен (кроме простейших случаев)?

    ОтветитьУдалить
  2. Ну он просто собрал недостатки Java/C++ в кучку и сказал что в Go это всё сделано правильно. Ну как автора его понять можно.
    А Go конечно интересная штука, но пока не понятно что из этого получится и какие реальные косяки вылезут или нет.

    ОтветитьУдалить
  3. 4:30 ...they [programmers] think that the way their languages make them think is really the right way to think about software...

    как говорится, "не в бровь а в глаз"

    P.S. Спасибо за отличный блог

    ОтветитьУдалить
  4. @Дмитрий Scriptin: Вопрос в том, что считается, что в С++ надо использовать паттерны (один singleton чего стоит), иначе программа не будет "правильной".

    ОтветитьУдалить
  5. Вопрос не в том - будет программа "правильной" или "неправильной". Проблема в том, что чаще всего шаблон появляется не на пустом месте, а в результате хождения по граблям. Использование же шаблона позволяет избежать повторного хождения по граблям.

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

    ОтветитьУдалить
  6. @Александр: если не использовать шаблон там, где он действительно нужен, то скорее всего программа окажется неправильной без всяких кавычек. Их же не ради забавы придумали и не ради создания "профессионального имиджа" языков.

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

    @rs: От граблей шаблоны тоже спасают, но мне видится, что это не основное их предназначение. Шаблоны - это такие трафареты для велосипедов, предназначание которых - экономить время на решениях типичных задач.

    ОтветитьУдалить
  7. @Дмитрий Scriptin: Дык да, паттерны хороши, когда они использованы ровно там, где нужны и ровно так, как должны. Ничто так не радует глаз, как удачное применение Observer или Command, или ещё чего...

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

    "Умные" указатели, самостоятельно высвобождающие память в C++, - это тоже паттерн. Только они скорее - АНТИпаттерн. И каждый паттерн является антипаттерном - костылём - в каком-то смысле. Вот про это и речь.

    ОтветитьУдалить
  8. Go - это убожище, граничащее с изотерикой. Куча народу была бы благодарна Гуглу, если бы только у них хватило ума продвигать не этот недоязычок, а D 2.0 - ему очень не хватает нормального компилятора.

    ОтветитьУдалить
  9. А может быть "нормальный язык", если у него нет "нормального" компилятора? C# неплохой язык по своей идее, но имплементация компиляторов заставляет плакать. И как быть?

    ОтветитьУдалить
  10. А каким образом язык связан с его реализацией? Плохо учились? :D
    C# явно уступает плюсам. А вот с компилятором проблем не вижу, хотя и пишу в данный момент именно на шарпе.

    ОтветитьУдалить
  11. Собственно, мои претензии к шарпу:
    1. Отсутствие множественного наследования. И не надо говорить, что это зло. Зло - это кривые руки. Больше всего убийств совершается кухонным ножом, но их же никто не запрещает. Надо уметь пользоваться своим инструментом, а не говорить "это может привести к сложностям".
    2. Неотключаемый GC. Что приводит к недетерминированному уничтожению объектов.
    3. Generic'и. Они явно создавались не как средство обобщённого программирования, а как средство создания пусть лишь _слегка_ обобщённого, но зато _закрытого_ кода. В нескольких книжках читал, что их основное преимущества перед плюсовыми шаблонами - отсутствие необходимости поставлять исходники библиотеки. Долго ржал :)))
    4. Коллекции. Они построены на динамическом полиморфизме. Как результат - даже компаратор надо передавать правильно :) http://habrahabr.ru/blogs/net/69520/

    Теперь по D 2.0. Официальный компилятор от Digital Mars под 32 бита. Другая хорошая реализация на основе LLVM - ldc - почему-то использует стандартную библиотеку от D 1.0. С реализацией gdc тоже какие-то траблы... не помню уже... :)
    Но это всё проблемы организационные/отсутствия денег/маленького коммьюнити. Здесь бы Гугль и мог помочь. Но это проблемы никак не языка! Возможность создания компилятора с качественным кодогенератором наглядно показана. Сам язык почти что идеален :) IMHO, конечно. Отключаемый GC, отсутствие макросов, плюсовые шаблоны, статические проверки при компиляции, юнит тесты в языке, примеси заменяют множественное наследование... Короче, всё гораздо круче куцего Go, про который мне хватило этих строчек в вики:
    У Go отсутствуют такие возможности как:
    * обработка исключений,
    * наследование типов,
    * обобщённое программирование,
    * использование утверждений
    * использование переопределение методов
    Узнавать больше об этом "языке" сразу расхотелось.

    ОтветитьУдалить
  12. @mir: "Умные" указатели в C++ - это скорее идиома языка, а не шаблон. В остальном согласен.

    @Tier: а что в нем эзотерического?

    ОтветитьУдалить
  13. Дмитрий Scriptin, я сказал "граничит". В том смысле, что ещё немного, и его нельзя будет использовать в реальных разработках.

    ОтветитьУдалить
  14. @Tier: "Еще немного" вряд ли случится. Наоборот, они теперь начнут ожесточенно добавлять все то, от чего первоначально отказались, и язык превратится в эклектическую свалку =)

    Или второй вариант: из-за недостатка возможностей придумают 9000 шаблонов проектирования и идиом для Go, а потом мистер Пайк будет выступать с докладом о том, какой замечательный это язык, что на нем возможно создать столько универсальных архитектурных решений ;D

    ОтветитьУдалить
  15. Настоящий программист напишет программу на фортране на любом языке программирования

    ОтветитьУдалить
  16. Если в go так много достатков, почему он слабо популярен?
    Хороший язык всегда заметят и воздвигнут. Значит он не такой уж идеальный, как сказал Пайк.

    ОтветитьУдалить
  17. @hromjo: корреляция между техническим совершенством язка и его популярностью не всегда очевидна. Haskell более выразителен, чем C++, но менее популярен из-за высокого порога вхождения.

    К тому же, существует класс "традиционных" промышленных языков, которые вымрут еще не скоро, несмотря на все свои недостатки. Яркий пример - Delphi, который до сих пор кое-где используется, по крайней мере в России. Одним словом, зависимость есть.

    И вообще, Пайк не называл Go идеальным. Он только сказал, что программировать на нем "забавно" (fun). Чисто поржать язык =)

    ОтветитьУдалить
  18. С какой стати Delphi является промышленным языком?

    ОтветитьУдалить
  19. @Andrey: а 1С - промышленный язык? Если считать промышленностью не только сырьедобавающие и обрабатывающие производства, но и другие предприятия - вполне себе пишут и на Delphi.

    А по теме - я солидарен с Tier'ом: Очки сделали бы больше пользы, развив D. Он сильно вкуснее этого Го.

    ОтветитьУдалить
  20. Согласен с посылом, паттерны - это часто своего рода workarounds языка, причем GoF создавались для C++ подбоных языков и решали их проблемы. Взять тот же C# - там паттерн subscriber/notifier является частью языка (events), синглтон уже почти тоже часть языка. Но еще четче понимаешь, что происходит, когда смотришь другие языки, взять тот же JS - там тоже Decorator просто не нужен, а Prototype - часть языка. Однако, важно понимать, что во многих случаях паттерны знать все равно нужно, просто они подаются не как паттерны, а как конструкции языка. И, кстати, польза изучения других языков на лицо - ведь если что-то видишь интересное в другом языке, то вполне вероятно сможешь придумать паттерн, дающий те же возможности, в языке, на котором приходится сейчас писать.

    ОтветитьУдалить
  21. Насчет Go идеи вполне разумные.
    Например, что дает обработка исключений? В случае если что-то пошло не так, мы можем это отследить и обработать. И получается, вместо предвратиельной проверки данных получаем постпроверку. Но постпроверка не исключает необходимость проверять данные вообще. Результат: размазали логику валидации данных по коду, причем в таком коде нет единообразия.
    А уже очень много кода и библиотек c++, java, c# и других завязаны на исключения. В результате получаем такую "красивую" систему обработки внештатных ситуаций, что понять ее и тестировать проблематично.
    Шикарный пример Hibernate: EntityManager.find() если элемент не найден возвращает null, Query если элемент не найден выбрасывает Exception, так же ексепшены возникают если не те данные пихать. Первый случай все ок - нет элемента и все тут, второй дивно выглядит рядом с первым, а третий вообще жесть - если я написал говнокод, который невалидирует данные перед отправкой в БД, то нельзя давать мне возможности это сокрыть, как будто все так и должно быть.

    ОтветитьУдалить