LINUX.ORG.RU

История изменений

Исправление svyatozar, (текущая версия) :

Очень часто бывает что в компании решения принимаются не программистами, либо теми из них, кто выше по служебной лестнице, но ниже по интеллекту. Я когда фрилансил с этим часто сталкивался. Я им говорю: проще сжать и перевести в jpeg картинки на сервере заранее, а не в момент запроса. Мне: «нет, там 80 терабайт - это всё сжать нереально и хранить сжатое негде». Дык сжатое же займёт всего 5% места? Нет и всё…

Или другой случай: работал над оконным менеджером для Линукса, где заказчик хотел чтобы окна можно было плавно «приближать и удалять» как видеокамерой без аппаратного ускорения (OpenGL, например). Это при том что все элементы оконного интерфейса заказчик требовал сделать в SVG. То есть, на каждый фрейм полноэкранной анимации, надо было делать растеризацию всех окон при максимальном удалении). Особенно трудно бывает, когда заказчик платит деньги, а над тобой ещё своего программиста ставит, который деньги не платит, но «настойчиво советует» как лучше сделать…

Ну а по большому счёту да: писать на Си только чтобы избежать ООП - это бред, конечно. Можно и на Си++ писать без ООП. Ну или с минимальным ООП в некритических местах. Я так и делаю, в принципе… Зато на Си++ отличная поддержка многопоточности. Никто не заставляет выделять память динамически: используй свои структуры, без контейнеров STL и всё. Делов-то! Кстати, и обратное тоже верно: на Си ещё как можно в стиле ООП писать, как это делается в GTK.

Исправление svyatozar, :

Очень часто бывает что в компании решения принимаются не программистами, либо теми из них, кто выше по служебной лестнице, но ниже по интеллекту. Я когда фрилансил с этим часто сталкивался. Я им говорю: проще сжать и перевести в jpeg картинки на сервере заранее, а не в момент запроса. Мне: «нет, там 80 терабайт - это всё сжать нереально и хранить сжатое негде». Дык сжатое же займёт всего 5% места? Нет и всё…

Или другой случай: работал над оконным менеджером для Линукса, где заказчик хотел чтобы окна можно было плавно «приближать и удалять» как видеокамерой без аппаратного ускорения (OpenGL, например). Это при том что все элементы оконного интерфейса заказчик требовал сделать в SVG. То есть, на каждый фрейм полноэкранной анимации, надо было делать растеризацию всех окон при максимальном удалении). Особенно трудно бывает, когда заказчик платит деньги, а над тобой ещё своего программиста ставит, который деньги не платит, но «настойчиво советует» как лучше сделать…

Ну а по большому счёту да: писать на Си только чтобы избежать ООП - это бред, конечно. Можно и на Си++ писать без ООП. Ну или с минимальным ООП в некритических местах. Я так и делаю, в принципе… Зато на Си++ отличная поддержка многопоточности. Никто не заставляет выделять память динамически: используй свои структуры, без контейнеров STL и всё. Делов-то!

Исходная версия svyatozar, :

Очень часто бывает что в компании решения принимаются не программистами, либо теми из них, кто выше по служебной лестнице, но ниже по интеллекту. Я когда фрилансил с этим часто сталкивался. Я им говорю: проще сжать и перевести в jpeg картинки на сервере заранее, а не в момент запроса. Мне: «нет, там 80 терабайт - это всё сжать нереально и хранить сжатое негде». Дык сжатое же займёт всего 5% места? Нет и всё…

Или другой случай: работал над оконным менеджером для Линукса, где заказчик хотел чтобы окна можно было плавно «приближать и удалять» как видеокамерой без аппаратного ускорения (OpenGL, например). Это при том что все элементы оконного интерфейса заказчик требовал сделать в SVG. То есть, на каждый фрейм полноэкранной анимации, надо было делать растеризацию всех окон при максимальном удалении). Особенно трудно бывает, когда заказчик платит деньги, а над тобой ещё своего программиста ставит, который деньги не платит, но «советует» как лучше сделать…

Ну а по большому счёту да: писать на Си только чтобы избежать ООП - это бред, конечно. Можно и на Си++ писать без ООП. Ну или с минимальным ООП в некритических местах. Я так и делаю, в принципе… Зато на Си++ отличная поддержка многопоточности. Никто не заставляет выделять память динамически: используй свои структуры, без контейнеров STL и всё. Делов-то!