Из этого небольшого видео, где автор и идеолог языка GO Роб Пайк делится своим недовольством языками С++ и Java, я вынес для себя классную мысль: в С++ и Java очень "важно" знать и использовать паттерны (какой уважающий себя программист на этих языках не знает хотя бы одного паттерна?), но наличие паттернов (а особенно их обилие) - это отрицательное свойство! То есть знание языка как такового - это еще полдела, так как затем надо еще и знать "правильные" паттерны.
Вобщем, я становлюсь фанатом этого дядьки.
Update: А комментарий с семью различными типами умных указателей в Бусте - это вообще шедевр.
четверг, 19 августа 2010 г.
Подписаться на:
Комментарии к сообщению (Atom)
Сообщения
Как будто нельзя те же шаблоны использовать в языках с динамической типизацией и в Go. Я бы сказал так: не все шаблоны одинаково полезны. Но что можно предложить взамен (кроме простейших случаев)?
ОтветитьУдалитьНу он просто собрал недостатки Java/C++ в кучку и сказал что в Go это всё сделано правильно. Ну как автора его понять можно.
ОтветитьУдалитьА Go конечно интересная штука, но пока не понятно что из этого получится и какие реальные косяки вылезут или нет.
4:30 ...they [programmers] think that the way their languages make them think is really the right way to think about software...
ОтветитьУдалитькак говорится, "не в бровь а в глаз"
P.S. Спасибо за отличный блог
@Дмитрий Scriptin: Вопрос в том, что считается, что в С++ надо использовать паттерны (один singleton чего стоит), иначе программа не будет "правильной".
ОтветитьУдалитьВопрос не в том - будет программа "правильной" или "неправильной". Проблема в том, что чаще всего шаблон появляется не на пустом месте, а в результате хождения по граблям. Использование же шаблона позволяет избежать повторного хождения по граблям.
ОтветитьУдалитьПоэтому "плохим" качеством С++ (для начинающих) является то, что язык не заставляет использовать эти паттерны. При этом в большинстве книг этому почти не уделяется внимания (или уделяется но не акцентируется в достаточной степени).
@Александр: если не использовать шаблон там, где он действительно нужен, то скорее всего программа окажется неправильной без всяких кавычек. Их же не ради забавы придумали и не ради создания "профессионального имиджа" языков.
ОтветитьУдалитьПоэтому с фразой "считается, что в С++ надо использовать паттерны" я категорически не согласен. Шаблоны используются везде, где они необходимы, и где язык не имеет встроенных решений для рассматриваемых задач.
@rs: От граблей шаблоны тоже спасают, но мне видится, что это не основное их предназначение. Шаблоны - это такие трафареты для велосипедов, предназначание которых - экономить время на решениях типичных задач.
@Дмитрий Scriptin: Дык да, паттерны хороши, когда они использованы ровно там, где нужны и ровно так, как должны. Ничто так не радует глаз, как удачное применение Observer или Command, или ещё чего...
ОтветитьУдалитьПроблема в том, что их *приходится* применять. И я соглашусь с теми, кто скажет, что лучше тот язык, в котором потребность в паттернах меньше.
"Умные" указатели, самостоятельно высвобождающие память в C++, - это тоже паттерн. Только они скорее - АНТИпаттерн. И каждый паттерн является антипаттерном - костылём - в каком-то смысле. Вот про это и речь.
Go - это убожище, граничащее с изотерикой. Куча народу была бы благодарна Гуглу, если бы только у них хватило ума продвигать не этот недоязычок, а D 2.0 - ему очень не хватает нормального компилятора.
ОтветитьУдалитьА может быть "нормальный язык", если у него нет "нормального" компилятора? C# неплохой язык по своей идее, но имплементация компиляторов заставляет плакать. И как быть?
ОтветитьУдалитьА каким образом язык связан с его реализацией? Плохо учились? :D
ОтветитьУдалитьC# явно уступает плюсам. А вот с компилятором проблем не вижу, хотя и пишу в данный момент именно на шарпе.
Собственно, мои претензии к шарпу:
ОтветитьУдалить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 отсутствуют такие возможности как:
* обработка исключений,
* наследование типов,
* обобщённое программирование,
* использование утверждений
* использование переопределение методов
Узнавать больше об этом "языке" сразу расхотелось.
@mir: "Умные" указатели в C++ - это скорее идиома языка, а не шаблон. В остальном согласен.
ОтветитьУдалить@Tier: а что в нем эзотерического?
Дмитрий Scriptin, я сказал "граничит". В том смысле, что ещё немного, и его нельзя будет использовать в реальных разработках.
ОтветитьУдалить@Tier: "Еще немного" вряд ли случится. Наоборот, они теперь начнут ожесточенно добавлять все то, от чего первоначально отказались, и язык превратится в эклектическую свалку =)
ОтветитьУдалитьИли второй вариант: из-за недостатка возможностей придумают 9000 шаблонов проектирования и идиом для Go, а потом мистер Пайк будет выступать с докладом о том, какой замечательный это язык, что на нем возможно создать столько универсальных архитектурных решений ;D
Настоящий программист напишет программу на фортране на любом языке программирования
ОтветитьУдалитьЕсли в go так много достатков, почему он слабо популярен?
ОтветитьУдалитьХороший язык всегда заметят и воздвигнут. Значит он не такой уж идеальный, как сказал Пайк.
@hromjo: корреляция между техническим совершенством язка и его популярностью не всегда очевидна. Haskell более выразителен, чем C++, но менее популярен из-за высокого порога вхождения.
ОтветитьУдалитьК тому же, существует класс "традиционных" промышленных языков, которые вымрут еще не скоро, несмотря на все свои недостатки. Яркий пример - Delphi, который до сих пор кое-где используется, по крайней мере в России. Одним словом, зависимость есть.
И вообще, Пайк не называл Go идеальным. Он только сказал, что программировать на нем "забавно" (fun). Чисто поржать язык =)
С какой стати Delphi является промышленным языком?
ОтветитьУдалить@Andrey: а 1С - промышленный язык? Если считать промышленностью не только сырьедобавающие и обрабатывающие производства, но и другие предприятия - вполне себе пишут и на Delphi.
ОтветитьУдалитьА по теме - я солидарен с Tier'ом: Очки сделали бы больше пользы, развив D. Он сильно вкуснее этого Го.
Согласен с посылом, паттерны - это часто своего рода workarounds языка, причем GoF создавались для C++ подбоных языков и решали их проблемы. Взять тот же C# - там паттерн subscriber/notifier является частью языка (events), синглтон уже почти тоже часть языка. Но еще четче понимаешь, что происходит, когда смотришь другие языки, взять тот же JS - там тоже Decorator просто не нужен, а Prototype - часть языка. Однако, важно понимать, что во многих случаях паттерны знать все равно нужно, просто они подаются не как паттерны, а как конструкции языка. И, кстати, польза изучения других языков на лицо - ведь если что-то видишь интересное в другом языке, то вполне вероятно сможешь придумать паттерн, дающий те же возможности, в языке, на котором приходится сейчас писать.
ОтветитьУдалитьНасчет Go идеи вполне разумные.
ОтветитьУдалитьНапример, что дает обработка исключений? В случае если что-то пошло не так, мы можем это отследить и обработать. И получается, вместо предвратиельной проверки данных получаем постпроверку. Но постпроверка не исключает необходимость проверять данные вообще. Результат: размазали логику валидации данных по коду, причем в таком коде нет единообразия.
А уже очень много кода и библиотек c++, java, c# и других завязаны на исключения. В результате получаем такую "красивую" систему обработки внештатных ситуаций, что понять ее и тестировать проблематично.
Шикарный пример Hibernate: EntityManager.find() если элемент не найден возвращает null, Query если элемент не найден выбрасывает Exception, так же ексепшены возникают если не те данные пихать. Первый случай все ок - нет элемента и все тут, второй дивно выглядит рядом с первым, а третий вообще жесть - если я написал говнокод, который невалидирует данные перед отправкой в БД, то нельзя давать мне возможности это сокрыть, как будто все так и должно быть.