Меня вообще этот Fallout не зацепил, да, стилистика узнаваема, но блин, обливион со стилистикой Fallout это ведь не Fallout, реально нет много того, что было в первых 2-х. Ждал редактор, теперь жду появление модов, тогда и попробую поиграть.
PHP имеет противоречивое именование системных и библиотечных функций. Предсказуемые схемы именования имеют важное значение в любом языке.
В этом больша проблема, постоянно требует отвлечение на документацию, а полноценную IDE для мелких правок я не использую, да и часто именование параметров не дает информации о том, что требуется туда передать.
PHP разработчики постоянно отказываются от встроенных функций и низкоуровневой функциональности. Наглядным примером является отказ от возможности передачи в функцию параметров по ссылке.
Я не заметил ничего хорошего в отказе, новичок будет учиться и поймет, что да к чему. А вот возвращать результаты в стиле Объект или false, возвращать массивы и т.д., вот это действительно криво, потому-что переходя с других языков непонятки, а при переходе на другие проблемы, потому что это вносит неточности в описание функций.
Чрезмерное применение пребразования типов приводит к ошибкам. У меня нет проблем с преобразованием, скажем, float в int и обратно. Но PHP (когда я последний раз проверял) с радостью попробует преобразовать массив в целое.
это болезнь всех нетипизированных языков и она часто портит жизнь, особенно когда над одним проектом работает куча народу и вносит правки в какие-либо большие функции, да и нетипизированность приводит к куче дыр.
Производительность PHP ужасна без кэширования. Скажите, кто-нибудь продаёт коммерческий продукт кэширования для PHP? Ах да, это делают сами разработчики PHP.
Конкретно про скорость ничего не скажу, тот же ASP.NET например умеет кэшировать сразу, для PHP есть и бесплатные продукты, для кэширование скомпилированного кода. Но как то давно, уже точно не вспомню, вроде как PHP 4, 5-й версии еще не было, в документации было сравнение производительности PHP с другими языками программирования, где разработчики как то пытались показать, что PHP шустее Perl, Pyton, C++ и т.д. Видимо просто мания величия вместе с самообманом.
И небольшой вывод ко всему. Ядро PHP разрабатывает компания Zend и делает более или менее качественно, библиотеки же разрабатывают уже непонятно кто, куда может попасть любой дилетант, который умеет цитировать умные книжки своими словами и непонятно зачем они лезут в ядро, считая, что они умнее профессионалов, вносят хаотичные исправления и т.д. из-за этого ругают компанию Zend, ругают авторов книг и т.д. На самом деле PHP может стать хорошим продуктом в том случае, если разрабатывать библиотеки, собирать его и т.д. определенная группа проверенных людей и будет какая-то стандартизация.
Основная проблема, что работодатели в основном считают это пустой тратой времени. Надо быстро все сделать и им не важна скорость, им важен результат. А на TDD по началу времени надо потратить больше, а то что в будущем это приведет к экономии времени, на это работодатель не смотрит.
Я всегда считал, что лучше заплатить чуть побольше, при этом получить надежность и сохранить гарантию. Да и скорость проца это не только частота, это еще и кэш, соответственно, даже если и разогнать более слабый проц, с мелким кэшем, то он никак не догонит старшего брата, при этом он будет работать как обогреватель, соответственно надо лучше охлаждение, на охлаждение опять нужны деньги, у меня сейчас при максимальной нагрузке E8400 не греется выше 40 градусов вообще.
Теперь же если надо кодировать видео, так выгоднее реально взять 4 ядра, заметно быстрее, а потеря 10% при кодировании видео в домашних условиях меня не напрягает, поставил на ночь и все, не так и часто делается, на Athlon 64+ 3200 жал и нормально.
Как-то один раз проц пожог, больше не хочется.
А по поводу статей, считаю, что надо тестировать все же те частоты, на что расчитано железо, описывать стабильность работы, комплектацию и т.д., при этом интересны именно сравнительные обзоры или краткое сзложение, чтобы удобно было сравнить с другими моделями.
Особенно когда на работем компе 512 метров и компания жмется увеличить этот объем или вторая ситуация, когда надо штук 5 открыть, да + к этому пару сред разработки, что-нить для UML, документация, куча браузеров, 80 метров ой как критично становится.
Еще одна война, которая выльется всем, кто использует данные продукты. В одном браузере одно работает, в другом другое, там баги, там дыры, в итоге опять маятся также как с браузерами.
Смотря как сделана упаковка, бывают такие края, что действуют не хуже лезвия, даже случайно чуть провести пальцем и порез обеспечен, а если учесть, что русский в первую очередь попробует открыть именно своей силой и зубами, то думаю в России травм в разы больше. А вообще есть ведь и не пропаянные упаковки, которые руками отлично вскрываются.
Идея интересная, но в плане юзабилити лишнее, мне ничем в плане навигации не поможет, ну я могу подсчитать кол-во абзацев, мне это ничего не даст, что там написано я не вижу, максимум, на картинку навести, с тем же успехом я могу просто проскролировать стандартным скроллбаром, но при этом данный выводит лишнюю информацию, которая может отвлечь от основного содержимого.
Quadro FX никогда на геймеров не ориентировались и никогда на них не делались игры, ибо в технологическом плане отставали, а выигрывали только в скорости расчетов. В играх и эта скорее всего проиграет GeForce X280.
Видимо люди стадные животные, один сказал IE отстой, все сразу закричали IE отстой. Ну а например работа с памятью в Firefox, его скорость работы оставляют желать лучшего. Я например Firefox только для работы использую из-за firebug и более он мне не нужен. А вот IE использую, потому что ничего дополнительного ставить не надо.
да, запятая самое то и наглядно и не будет последствий от переименования,
но вот у майкрософт бывают загоны, далее выпустят C# 4.1, в нем будет запятой пропускаться.
boost это вещь, давай, жги!
В этом больша проблема, постоянно требует отвлечение на документацию, а полноценную IDE для мелких правок я не использую, да и часто именование параметров не дает информации о том, что требуется туда передать.
PHP разработчики постоянно отказываются от встроенных функций и низкоуровневой функциональности. Наглядным примером является отказ от возможности передачи в функцию параметров по ссылке.
Я не заметил ничего хорошего в отказе, новичок будет учиться и поймет, что да к чему. А вот возвращать результаты в стиле Объект или false, возвращать массивы и т.д., вот это действительно криво, потому-что переходя с других языков непонятки, а при переходе на другие проблемы, потому что это вносит неточности в описание функций.
Чрезмерное применение пребразования типов приводит к ошибкам. У меня нет проблем с преобразованием, скажем, float в int и обратно. Но PHP (когда я последний раз проверял) с радостью попробует преобразовать массив в целое.
это болезнь всех нетипизированных языков и она часто портит жизнь, особенно когда над одним проектом работает куча народу и вносит правки в какие-либо большие функции, да и нетипизированность приводит к куче дыр.
Производительность PHP ужасна без кэширования. Скажите, кто-нибудь продаёт коммерческий продукт кэширования для PHP? Ах да, это делают сами разработчики PHP.
Конкретно про скорость ничего не скажу, тот же ASP.NET например умеет кэшировать сразу, для PHP есть и бесплатные продукты, для кэширование скомпилированного кода. Но как то давно, уже точно не вспомню, вроде как PHP 4, 5-й версии еще не было, в документации было сравнение производительности PHP с другими языками программирования, где разработчики как то пытались показать, что PHP шустее Perl, Pyton, C++ и т.д. Видимо просто мания величия вместе с самообманом.
И небольшой вывод ко всему. Ядро PHP разрабатывает компания Zend и делает более или менее качественно, библиотеки же разрабатывают уже непонятно кто, куда может попасть любой дилетант, который умеет цитировать умные книжки своими словами и непонятно зачем они лезут в ядро, считая, что они умнее профессионалов, вносят хаотичные исправления и т.д. из-за этого ругают компанию Zend, ругают авторов книг и т.д. На самом деле PHP может стать хорошим продуктом в том случае, если разрабатывать библиотеки, собирать его и т.д. определенная группа проверенных людей и будет какая-то стандартизация.
Теперь же если надо кодировать видео, так выгоднее реально взять 4 ядра, заметно быстрее, а потеря 10% при кодировании видео в домашних условиях меня не напрягает, поставил на ночь и все, не так и часто делается, на Athlon 64+ 3200 жал и нормально.
Как-то один раз проц пожог, больше не хочется.
А по поводу статей, считаю, что надо тестировать все же те частоты, на что расчитано железо, описывать стабильность работы, комплектацию и т.д., при этом интересны именно сравнительные обзоры или краткое сзложение, чтобы удобно было сравнить с другими моделями.
и также для других команд, да и расширяемость лучше, главное не путать бизнес логику и отображение.
но вот у майкрософт бывают загоны, далее выпустят C# 4.1, в нем будет запятой пропускаться.