> а вообще поймал себя на мысле что хочется именно проектировать…
Опасное желание. Если Вы не собираетесь делать это исключительно ради карьеры — лучше воздержитесь. Я уже ходил этой тропой — через год работы архитектором возникает чувство панического страха: технологии уплывают вперед, а ты, дорогой архитектор, каким был, таким и остался. Отсутствие практики в непосредственной разработке (читай «в кодировании») — губительная штука. А кодить, работая архитектором, не всегда получится. Максимум на что можно расчитывать — успевать читать заголовки топиков в блогах по профильным предметам.
Бог с ними, со сроками. Это тема отдельного разговора. Сейчас я веду к тому, что архитекторы aka проектировщики — это такая каста, которая, занимается абстрактным проектированием абстрактной системы для решения конкретных задач. Это страшные для программиста люди, потому что архитекторы далеки от реальности.
Самый страшный архитектор — это Главный Архитектор — как правило, программист в далеком прошлом — обычно он занимает должность технического директора конторы или около того. Такие люди смотрят на проектируемую систему сверху, и, соответственно, дизайнят ее «сверху-вниз», оставляя самый нижний слой на совести разработчика. А в попытке трансформации такой абстрации в реальность, зачастую случается конфуз (иногда — Очень Большой Конфуз, после которого вообще непонятно как двигать проект дальше).
Разработчик должен двигаться «снизу-вверх», потому что такой подход позволяет реализовывать задуманную абстракцию на надежном «нижнем» слое кода. Заковырка в том, что дизайнить систему «снизу-вверх» — сложно: разработчик не может знать, что ему понадобится _на самом деле_ на нижестоящем слое, пока не опробует нижестоящий слой на вышестоящем. Выходом в такой ситуации является TDD, которое, кстати, автоматически позволяет делать декомпозицию задачи на более мелкие кусочки (причем именно автоматически, прямо в процессе кодирования, не расписывая каждый шаг основной задачи).
Разработка снизу-вверх позволяет находить изъяны в используемой среде и строить систему, основываясь на этом знании (практический пример: все мейнстримовые браузеры [FF, IE, Opera] имеют баг работы с cookie. Только в Safari/WebKit корректно реализована поддержка cookie. Удивил? Для меня это тоже было сюрпризом).
Я наслышан о том, что Xen позволяет гостевой ОСи использовать железо напрямую, например, видеокарту. Так ли это на самом деле? Возможно ли, например, под Xen на линуксе поставить винду и сделать так, чтобы DirectX использовал аппаратное ускорение видеокарты?
Ну-ну, господа! Полно сопли пускать. Не все так печально. Вы забываете про два важных момента:
1. «Мне бы такой же, только с перламутровыми пуговицами».
Аналоги сервисам, которые вы описали, существовали/существуют на моей памяти, лет уже 8. Шоп-билдеры и сайт-билдеры всех мастей не делал только ленивый. Где они сейчас? Все там же. Беда этих сервисов заключается в том, что пользователь — зверёк непредсказуемый. Сегодня ему надо одно, завтра — другое. А SaaS не сделаешь персонально под каждого: рано или поздно наступит момент, когда сервис перестанет удовлетворять запросам пользователей в силу их многочисленности и «разношерстности». И побегут пользователи обратно к своим фрилансерам делать этот же SaaS «чуть-чуть другим». Вывод: роль интеграторов/программистов никуда не денется, просто мы будем называть себя по-другому: «Facebook Integrator» и так далее).
2. User Generated Applications (UGA).
Пользователи сами будут делать приложения это, при всем уважении, профанация. Знаете почему? Ответьте сами себе на вопрос: много ли ПОЛЕЗНОГО контента сгенерили пользователи в эпоху «уходящего Web 2.0»? Думаю, ответ очевиден. КПД полезности информации на большинстве страниц интернета стремится к нулю. О чем это говорит? Это говорит о том, что 99% UGA будут тем же самым бесполезным унылым говном, сделанным ради удовлетворения любопытства или собственного достоинтства.
Так что рано паниковать, господа программеры и IT-шнеги. На наш век программизма хватит с головой. А что будет потом… потом закончится нефть, газ, уголь, алмазы в Африке, разразится очередная Мировая, всех накроет напалмом и только космонавты с орбиты будут с тоской глазеть на все это безобразие через засранные иллюминаторы.
> почитайте хотя бы Страуструпа «Дизайн и эволюция С++» (знаю, не читали и читать не будете).
Товарищ, прежде чем делать подобные заявления, я бы рекомендовал хотя бы пролистать комменты за авторством khim на его хабрацентре. khim — один из редких представителей вымирающего вида Programmator Sapiens. Будьте повежливее, пожалуйста!
> Покажите мне язык, который по эффективности был сравним с С++ и имел бы существенно меньше недостатков.
Понятие «эффективность» в данном контексте включает затраты на разработку алгоритма (написание, отладка)?
Если влючает, то C++ нервно курит в сторонке. Тот же Haskel, OCaml и даже Common Lisp (SBCL) будут гораздо эффективнее C++. Если мы рассматриваем исключительно эффективность кода — да, C++ рекордсмент.
Вопрос в том, кому сегодня нужна эффективность C++ от C++, когда топовые промышленные сервера содержат по 128 процессоров и по 2 терабайта RAM и есть ряд альтернативных языков, позволяющих сократить время разработки практически идентичного решения на тысячи процентов?
Множественное число здесь уместно не по причине множественного наследования [A, B, C] -> D, а по причине A -> B -> C -> D. Класс D будет иметь доступ к данным и методам своих предков (C -> B -> A).
А выбор между множественным наследованием и интерфейсами — воля разработчика. Или архитектора ;-)
Ну… до ООП надо еще дойти. Желательно самому. Ибо когда у человека есть на практике проблема а-ля [«это выглядит слишком громоздко», «слишком много повторений», «мне надоело тягать этот указатель из функции в функцию», «половина функций для работы с моими структурами являются клонами»], то эффект от осознания парадигмы ООП можно сопоставить… ну… э… как если бы вас шарахнуло молнией — помню по себе, когда в 1991 году я прикупил мааленькую брошурку за авторством Славы Чипа (вероятно, псевдоним), популярным языком объяснявшую суть ООП с примерами на BP — не передать словами, какие мысли вертелись в моей голове тогда ;-)
Не знать про ООП? Да как нефик делать. Например в JS классический ООП нафик не нужно знать — там все делается прототипы, замыкания и функторы. Lisp / Scheme — вообще ту применить любую парадигму, какая душе угодна.
А вообще, открою вам страшную тайну. Только цсс, ни-ко-му! [шепотом]: объектов не существует!
Copyright © Bruno Haible, Michael Stoll 1992, 1993
Copyright © Bruno Haible, Marcus Daniels 1994-1997
Copyright © Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright © Bruno Haible, Sam Steingold 1999-2000
Copyright © Sam Steingold, Bruno Haible 2001-2006
[1]> (- 500000000000002 500000000000001)
1
Вроде неплохо так считает. И точность не теряется ;-)
P.S. Хотел привести пример с (! 12345) но боюсь меня закидают камнями за 40Кб циферек :-D
factory(«news»)->do_print();
и
$news = new news();
$news->do_print();
будет очень непросто. Хотя бы потому, что в PHP не декларируется тип возвращаемого значения функции.
Опасное желание. Если Вы не собираетесь делать это исключительно ради карьеры — лучше воздержитесь. Я уже ходил этой тропой — через год работы архитектором возникает чувство панического страха: технологии уплывают вперед, а ты, дорогой архитектор, каким был, таким и остался. Отсутствие практики в непосредственной разработке (читай «в кодировании») — губительная штука. А кодить, работая архитектором, не всегда получится. Максимум на что можно расчитывать — успевать читать заголовки топиков в блогах по профильным предметам.
Самый страшный архитектор — это Главный Архитектор — как правило, программист в далеком прошлом — обычно он занимает должность технического директора конторы или около того. Такие люди смотрят на проектируемую систему сверху, и, соответственно, дизайнят ее «сверху-вниз», оставляя самый нижний слой на совести разработчика. А в попытке трансформации такой абстрации в реальность, зачастую случается конфуз (иногда — Очень Большой Конфуз, после которого вообще непонятно как двигать проект дальше).
Разработчик должен двигаться «снизу-вверх», потому что такой подход позволяет реализовывать задуманную абстракцию на надежном «нижнем» слое кода. Заковырка в том, что дизайнить систему «снизу-вверх» — сложно: разработчик не может знать, что ему понадобится _на самом деле_ на нижестоящем слое, пока не опробует нижестоящий слой на вышестоящем. Выходом в такой ситуации является TDD, которое, кстати, автоматически позволяет делать декомпозицию задачи на более мелкие кусочки (причем именно автоматически, прямо в процессе кодирования, не расписывая каждый шаг основной задачи).
Разработка снизу-вверх позволяет находить изъяны в используемой среде и строить систему, основываясь на этом знании (практический пример: все мейнстримовые браузеры [FF, IE, Opera] имеют баг работы с cookie. Только в Safari/WebKit корректно реализована поддержка cookie. Удивил? Для меня это тоже было сюрпризом).
Вы что, серьезно? Часто ли конечная реализация совпадает с изначально запланированной?
1. «Мне бы такой же, только с перламутровыми пуговицами».
Аналоги сервисам, которые вы описали, существовали/существуют на моей памяти, лет уже 8. Шоп-билдеры и сайт-билдеры всех мастей не делал только ленивый. Где они сейчас? Все там же. Беда этих сервисов заключается в том, что пользователь — зверёк непредсказуемый. Сегодня ему надо одно, завтра — другое. А SaaS не сделаешь персонально под каждого: рано или поздно наступит момент, когда сервис перестанет удовлетворять запросам пользователей в силу их многочисленности и «разношерстности». И побегут пользователи обратно к своим фрилансерам делать этот же SaaS «чуть-чуть другим». Вывод: роль интеграторов/программистов никуда не денется, просто мы будем называть себя по-другому: «Facebook Integrator» и так далее).
2. User Generated Applications (UGA).
Пользователи сами будут делать приложения это, при всем уважении, профанация. Знаете почему? Ответьте сами себе на вопрос: много ли ПОЛЕЗНОГО контента сгенерили пользователи в эпоху «уходящего Web 2.0»? Думаю, ответ очевиден. КПД полезности информации на большинстве страниц интернета стремится к нулю. О чем это говорит? Это говорит о том, что 99% UGA будут тем же самым бесполезным унылым говном, сделанным ради удовлетворения любопытства или собственного достоинтства.
Так что рано паниковать, господа программеры и IT-шнеги. На наш век программизма хватит с головой. А что будет потом… потом закончится нефть, газ, уголь, алмазы в Африке, разразится очередная Мировая, всех накроет напалмом и только космонавты с орбиты будут с тоской глазеть на все это безобразие через засранные иллюминаторы.
Видимо описочка? Речь идет про хост-систему? ;-)
Товарищ, прежде чем делать подобные заявления, я бы рекомендовал хотя бы пролистать комменты за авторством khim на его хабрацентре. khim — один из редких представителей вымирающего вида Programmator Sapiens. Будьте повежливее, пожалуйста!
> Покажите мне язык, который по эффективности был сравним с С++ и имел бы существенно меньше недостатков.
Понятие «эффективность» в данном контексте включает затраты на разработку алгоритма (написание, отладка)?
Если влючает, то C++ нервно курит в сторонке. Тот же Haskel, OCaml и даже Common Lisp (SBCL) будут гораздо эффективнее C++. Если мы рассматриваем исключительно эффективность кода — да, C++ рекордсмент.
Вопрос в том, кому сегодня нужна эффективность C++ от C++, когда топовые промышленные сервера содержат по 128 процессоров и по 2 терабайта RAM и есть ряд альтернативных языков, позволяющих сократить время разработки практически идентичного решения на тысячи процентов?
А почему так произошло — Вы не задумывались? И почему Вы уверены, что такая ситуация сохранится в обозримом будущем?
А выбор между множественным наследованием и интерфейсами — воля разработчика. Или архитектора ;-)
function factory($class) {
return new $class();
}
factory(«news»)->do_print();
отражает суть полиморфизма? :))
function foo(publications $p) { $p->do_print(); }
вот тогда это будет статья про полиморфизм. ;-)
А вообще, открою вам страшную тайну. Только цсс, ни-ко-му! [шепотом]: объектов не существует!