Мне кажется AMD демонстрирует как здоровая конкуренция может благотворно влиять на ситуацию на рынке. Благотворно в первую очередь для простых пользователей.
Не запрещает, а рекомендует не использовать в целях единого стиля. Если каждый будет писать как ему хочется — читать и переключаться с одного стиля кода на другой будет неудобно. Код чаще читается чем пишется, так почему бы не сделать сразу и хорошо?
Статья интересна, как минимум как взгляд одинокого независимого разработчика на легкую форму gamedev-а, тем более что пару подводных камней и советов не помешают другому одинокому разработчику.
Даже в святая святых космического изучения, вроде бы одной из самых амбициозных и важных надежд человечества на будущее бушует бюрократия. С одной стороны денег на будущее жалеть и не хочется, но с другой они то могут пригодиться сейчас в другой сфере. Сложно, а мама меня ещё не забрала из садика.
Годная статья. Объемы информации и следы оставляемые при использовании современных гаджетов впечатляют — остается лишь правильно поискать. Сделать что-то и не оставить следа становится сложнее, а учитывая что сбор информации работает не только на благо, хочется просто быть осторожнее.
позволяющее расслабиться и отдохнуть в любом месте: на природе, в аэропорту
Мне искренне любопытно, тот кто описывал такое применение бивана хотя бы представлял себе как можно надуть эту здоровенную хреновину в аэропорту (не говоря про громоздкость, помехи другим посетителям, и наконец обратной упаковке)?
Основным плюсом этого алгоритма является то, что объекты удаляются сразу как только они не нужны.
Этот метод практически не уступает по производительности ручному управлению памятью, но при этом позволяет существенно сократить количество присущих ему ошибок. Поддержка кода также упрощается.
А каким алгоритмом собственно предлагаете его заменить?
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let's do more of those!
Жаль что нету в текстовом формате. Хотя тут наверное полезнее были бы статьи от каждого из спикеров в сжатой (в разумных пределах) форме. 10 часов видео осилить это прям-таки вызов (разве что на который мало кто откликнется).
Беларуси
нудный mode off
Мне кажется это цитата на миллион. Хотя пожалуй не для России.
одинокогонезависимого разработчика на легкую форму gamedev-а, тем более что пару подводных камней и советов не помешают другомуодинокомуразработчику.Мне искренне любопытно, тот кто описывал такое применение бивана хотя бы представлял себе как можно надуть эту здоровенную хреновину в аэропорту (не говоря про громоздкость, помехи другим посетителям, и наконец обратной упаковке)?
Этот метод практически не уступает по производительности ручному управлению памятью, но при этом позволяет существенно сократить количество присущих ему ошибок. Поддержка кода также упрощается.
А каким алгоритмом собственно предлагаете его заменить?
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let's do more of those!