Можно поинтересоваться, как вы решили из приведенной цитаты, что сам радиотелескоп (антенна + приемник) не сделан в России? А то называть такой прибор болванкой как-то странно.
Мне лично кажется, что отсутствие кроссплатформенности — это ощутимый недостаток. Я пишу как раз на OpenCL из-за этого, а также потому, что OpenCL действительно весьма и весьма близок к С. Вплоть до того, что необходимо изучить только пару специфичных функций типа получения номера потока и иметь под рукой спецификацию.
Я к тому, что используются одни и те же средства, а не 2 разные по идеологии и методам библиотеки. Оптимизации — это отдельная проблема, ведь часто приходится учитывать особенности каждой модели GPU и соответственно корректировать код.
Удобство — это когда как. Вот для научных вычислений лучше бывает архитектура shared memory. Например, для расчётов методом «частицы-в-ячейках» для каждого потока требуются параметры всех частиц, поэтому message-passing не очень катит.
В статье многовато философии, по моему мнению. А философия плоха тем, что отворачивает взор от практики.
1е возражение — довольно спорно. Если юзается объект, значит у него есть некоторое внутреннее состояние. Внутреннее состояние (в виде структур данных) бесполезно, если оно никак не связано с внешним миром. А связано оно через методы. Так что получается, что структуры данных и функции для работы над ними не являются абсолютно разными вещами, а скорее частями одного целого.
С остальными аргументами более-менее согласен. Вообще приятно видеть, когда возражения против ООП адекватны, а не вытекают из непонимания концепций ООП спорящим (как на знаменитом избиении ООПшников на их же конференции).
Я так и не понял — теория верна, если правильно описывает явления с количественной точки зрения. А тут как раз описывает. Ну подогнали, потом объяснение запилили. Я не вижу в этом ничего плохого, пока теория верифицируема и фальсифицируема. Вы же не будете навязывать каноничный и авторитетный путь познания? Ну и все наши теории — всегда некое (иногда достаточно точное) приближение реального положения дел.
Кстати, поясните, что вы подразумеваете под «описать» и «объяснить». Кажется, тут есть недопонимание.
Можете объяснить простому человеку, чем это принципиально лучше стандартных рекомендаций (те, что можно почитать при помощи man gitworklows)? Мне вообще кажется, что тогда репозиторий почище будет, да и вручную, без скриптов их использовать попроще.
Удобство — это когда как. Вот для научных вычислений лучше бывает архитектура shared memory. Например, для расчётов методом «частицы-в-ячейках» для каждого потока требуются параметры всех частиц, поэтому message-passing не очень катит.
Да вы прямо как суровые челябинские мужики! А если серьезно, почему SCM так не любите?
1е возражение — довольно спорно. Если юзается объект, значит у него есть некоторое внутреннее состояние. Внутреннее состояние (в виде структур данных) бесполезно, если оно никак не связано с внешним миром. А связано оно через методы. Так что получается, что структуры данных и функции для работы над ними не являются абсолютно разными вещами, а скорее частями одного целого.
С остальными аргументами более-менее согласен. Вообще приятно видеть, когда возражения против ООП адекватны, а не вытекают из непонимания концепций ООП спорящим (как на знаменитом избиении ООПшников на их же конференции).
Кстати, поясните, что вы подразумеваете под «описать» и «объяснить». Кажется, тут есть недопонимание.