SPSS теперь и для Linux

а че, пайтон это хорошо )

Имхо зря они пистон выбрали, тормоз это и для серьезных расчетов не годится, а если учесть, что 80% скриптов будут написаны студиозами в ходе выполнения курсовых работ, то это будет тормоз в квадрате.

Sun-ch, сам ты тормоз )), если из питона будут вызовы расчетного ядра, в которых расчетная программа проводит от 90 до 99% времени, то все будет просто летать, а если учесть что посредством питона доступна вся его библиотека, то вообще вещь не плохая. btw, за аналогами ходить далеко не нужно -- mayavi, python-vtk, python-mpi, namd, mmtk и т.д.

Черт, отличная новость. Производители проприетарного ПО постепенно стали переходить на открытые ОС. Я рад, т.к. в статистике самым оптимальным является пока-что только SPSS (statistica не катит, не удобная, а SAS слишком большой продукт).

А из С нельзя вызывать расчетное ядро? Вырастет порог вхождения и качество скриптов, которые будут доступны как опенсорс заметно вырастет.

Замечательная новоть!

Я эту SPSS под вайном запускал. Запускались только версии не старше 10-й. Хорошо, что теперь родная будет. Плохо, что стоит она 1600 баксов...

А чем неоптимален для статистиков R?

Некоторые нейросетевые плагины для SPSS стоят под 200 000$.

Кстати, ни разу не видел свободных аналогов SPSS. Таковые имеются?

> А из С нельзя вызывать расчетное ядро? Вырастет порог вхождения и качество скриптов, которые будут доступны как опенсорс заметно вырастет.

Все можно, но из питона на порядок удобнее/проще/надежнее без потери производительности и без заметного увеличения требований по памяти. Подобная архитектура уже лет 5 минимум себя прекрасно зарекомендовала в узких кругах HPC (в основном выч. физика, химия, биология). Одна интерактивность + возможность писать быстрый код без нужды ковыряний в отладчике уже много стоит.

Задача скриптового языка расширения -- снизить порог вхождения для автоматизации рутинных автоматизационных задач для простых смертных пользователей-предметников.

А качество нужно в разработке модулей расширения для ядра, здесь рулит связка c/c++/fortran + python (есть еще деятели использующие связку fortran + java). А это уже задача для относительно узкого круга экспертов...

>Задача скриптового языка расширения -- снизить порог вхождения для автоматизации рутинных автоматизационных задач для простых смертных пользователей-предметников.

Это делается вовсе не для снижения порога вхождения, а затем, чтобы не тратить время на бесполезную рутинную работу.

> Это делается вовсе не для снижения порога вхождения, а затем, чтобы не тратить время на бесполезную рутинную работу.

Совершенно верно. Фраза про снижение порога вхождения относится к сентенции sun-ch'a про C и порог вхожления. Использование нормального скриптового языка (например, того же питон'а) дает всегда кумулятивный эффект от множества факторов.

Salstat http://salstat.sourceforge.net/ PSPP http://www.gnu.org/software/pspp/pspp.html R http://www.r-project.org/ Macanova http://www.stat.umn.edu/macanova/

Да, новость очень хорошая. Только вчера думал: "а когда будет SPSS для Линукс?". Вот! :)

> Имхо зря они пистон выбрали, тормоз это и для серьезных расчетов не годится

Между прочим, нашумевший проект расшифровки генома человека реализовывался именно на питоне.. (не вычислительное ядро, понятное дело)

>Только вчера думал: "а когда будет SPSS для Линукс?". Вот! :)

Если твои мысли сбываются, подумай о том, когда будут Abby FineReader и Adobe Photoshop (хотя зачем мелочиться, весь Creative Suite) для Linux=)

>А из С нельзя вызывать расчетное ядро? Вырастет порог вхождения и качество скриптов, которые будут доступны как опенсорс заметно вырастет.

Боюсь, что оно заметно упадет. Из-за for(int i=0; i<drive_nogi_kolobka; i++) вместо map/reduce/filter.

Собсно и для расчетного ядра, что C, что Fortran - ужасны. Для него нужен язык с более высоким уровнем абстракции. Но такой же быстрый. Например, С++. C и Fortran - это тяжелое наследие прошлого.

Ясень пень ужасны, даже c++ не подарок. Но жизнь, есть жизнь: тонны эффективного кода на Fortran и С. Переписывать с нуля обычно нет ни времени, ни денег, ни желания, а подходящего ООП-компонента может и не найтись. Тогда использовать ГОТОВЫЕ УНАСЛЕДОВАННЫЕ модули на Fortran/C для реализации внутреннего поведения объекта в c++-расчетном ядре, оперирующим абстракциями предметной области (например, матрица не является такой абстракцией для биолога )) ) никаких техничеких или концептуальных проблем нет. Разве что идеологические ))

> подходящего ООП-компонента может и не найтись.

нах он тебе нужен-то в расчетах?

> Собсно и для расчетного ядра, что C, что Fortran - ужасны. Для него нужен язык с более высоким уровнем абстракции. Но такой же быстрый. Например, С++. C и Fortran - это тяжелое наследие прошлого.

От прочитанного поперхнулся. Не шутите так больше.

>Ясень пень ужасны, даже c++ не подарок.

Я и не говорю, что надо переписывать. Отлаженные 10-летиями расчетные модули на фортране лучше, чем новодел. Да и невозможно переписать столько кода. Но факт остается фактом. Перегрузка операторов, вменяемые структуры данных, шаблоны, святая троица контейнер-итератор-алгоритм - лучше, чем for, if и goto.

А чем перегрузка операторов для счётных целей лучше? Что она экономит?

Это Вы так теоритезируете? Уверяю Вас жизнь гораздо конкретнее, чем шаблоны.

> нах он тебе нужен-то в расчетах?

Сложность друг мой, сложность. Современные расчетные системы это не 1000 и не 10000 строк рукописного кода, а намного, намного больше. Причем кода высокоуровневого, а не геттеры, сеттеры, паттерны в обработчиках gui-формы. Если есть выбор между старым примитивным кодом на fortran'e с equiv-блоками, goto и т.п. (ну вы меня поняли) и новым относительно более чистым ооп-кодом при сравнивой производительности, я предпочту последний. А новый код пишут постепенно, пишут во многих областях, по многим причинам. Например сравните blas,atlas,petsc.

Про мега-производительность программ на fortran'e сказки рассказывать тоже не нужно, плавали, проверяли на реальных задачах ради спортивного интереса. Если компилятор один + опции оптимизации одинаковы + железо одинаковое + алгоритм один + писал не индус, то проигрыш кода на c++ будет от 2-20% (за счет динамического выделения памяти, шаблонов, полимофизма и т.п. вещей). А выигрыш будет в объеме и читаемости кода. Хотя если конечно руки не от туда выросли, то потерять можно и 100-200%, но на том же фортране с теми же руками думаю тот же результат будет :)

Обобщенное программирование - позволяет рутинную работу по выводу и контролю типов переложить на компилятор.

Вот попробуй средствами фортрана опиши объекты типа гиперкомплексных чисел и операции над ними.

> Например сравните blas,atlas,petsc.

О да - то, как я слышу про то как они развиваются (обеспечение ATLAS) меня охватывает тихий ужас на тему как они это безобразие проверять будут. Физики очевидно пошли на поводу у программистов и в следствии этого огребут по полной.

Пользы от ООП нет, так как а) кода всё равно не меньше б) он не переиспользуется. ООП - это способ спрятать уродство за абстракцией.

>как они развиваются (обеспечение ATLAS)

Evgueni, это не тот ATLAS, который на LHC :) , это софтина для генерации оптимизированной библиотеки blas. А что касается уродства софта в эксперименте АТLAS, то с этим согласен.

Ааа, а то я уж испугался. Но IMHO в любом случае качество зависти от человека, а не от синтаксиса и в этом смысле серебрянной пули нет кроме как использовать уже имеющиеся наработки.

>Пользы от ООП нет, так как а) кода всё равно не меньше б) он не переиспользуется. ООП - это способ спрятать уродство за абстракцией.

Интересно, получилось бы написать тот же самый ROOT на С?

>>Пользы от ООП нет, так как а) кода всё равно не меньше б) он не переиспользуется. ООП - это способ спрятать уродство за абстракцией.

>Интересно, получилось бы написать тот же самый ROOT на С?

О - классный пример на тему, как хорошую идею (которая была уже реализована на Fortran) можно испортить с помощью ООП. Надеюсь, что тот же самый написать бы не получилось.

> Пользы от ООП нет, так как а) кода всё равно не меньше б) он не переиспользуется. ООП - это способ спрятать уродство за абстракцией.

Вот блин, а народ то и не знает, что пользы то нет :)

а) Объем кода. Есть такой экспериментальный факт, два разных человека на одном языке используя одну парадигму (в нашем случае ООП) получают два разных решения одной задачи выражаемой в числе рукописных строк кода, отличающеся на коэффициент 1-10. Надеюсь спортить не будете, что объем кода все-таки зависит от уровня языка? Ну например asm или c# для отрисовки формы под офтопиком?

б) Переиспользование. Не всегда это цель, если для разработчиков самих их творение становиться чище/логичнее/понятие, почему нет?

в) ООП - это средство управления сложностью. А уродство можно везде соорудить. Вот недавно в одной очень неплохой старой программке на fortran'e пытался увеличить число атомов. Вот там это число любезно забитой цифрой 100 в явном в виде наверно местах так в 100. И меток с таким значением тоже примерно столько. Настоящее уродство и на fortran :) Программка не плохая, широко и давно используется, разработчик-университет солидный буржуйский...

вендекапец близко) новость отличная, а R, безусловно, рулит!

> Интересно, получилось бы написать тот же самый ROOT на С?

На Фортране же получилось. И лучше даже чем потом на C++.

>А чем перегрузка операторов для счётных целей лучше? Что она экономит?

>Это Вы так теоритезируете? Уверяю Вас жизнь гораздо конкретнее, чем шаблоны.

Я Вас понимаю. Вы иронизируете по поводу java-way. Погрузить все и вся в ООП, использовать ORM, middleware и в итоге получить уродливого жирного кабана "для денег" (c) svu. Коими являются продукты Apache Foundation & Co. С наследством в 20 потомков и докой, в которой йух проссыш. Полностью согласен с Вами. Но это - крайность. Давайте посмотрим с другой стороны. С - это всего лишь макроассемблер. Как ни крутите. Красивый? Да. Высокоуровневый? Да. Но макроассемблер. C++, STL и шаблоны дают совсем другую свободу. Свободу крутить и вертеть как хочешь и чем хочешь. Почти как Питон. Посмотрите Boost. Там с помощью вышеперечисленных вещей делаются потрясающие вещи. Которые не являются абстракцией в 20 классов. Они - утилитарны. Они позволяют делать просто сложные вещи. Я прекрасно понимаю, что сейчас последует аргумент "что я не могу сделать на C, в отличии от C++?". Отвечу. Можете все. С тем же успехом, что и на хорошем макроассемблере. Или даже в машкодах. Но со значительно меньшим удобством. Ибо 2 + 3 * 5 гораздо проще, чем add(2,mul(3,5)).

>Но со значительно меньшим удобством. Ибо 2 + 3 * 5 гораздо проще, чем add(2,mul(3,5)).

Ты не поверишь, но 2 3 5 * + еще удобнее. Не стоит путать расчетчиков с програмистами - сие есть большая разница.

> Но это - крайность. Давайте посмотрим с другой стороны. С - это всего лишь макроассемблер.

Я не говорю, что C хорош. Он удобен тем, что система на нём написана. Я не говорю, что Fortran хорош - он достаточно неплох и имеет богатое наследие в виде вылизанных рабочих библиотек. Я говорю, что ООП - это отнюдь не серебряная пуля (преимущество ООП есть только в очень узком сегменте создания интерфейсов в основном графических, но и на С есть примеры превосходной функциональности и качества) , а реализация его на C++ в силу его сложности и "популярности" подталкивает к заведомо уродливым решениям. Как надо я не знаю, но говорить что C++ это спасение не стоит, потому что это не правда.

Мне не нужна потенциальная возможность - мне как пользователю нужно рабочее решение моей проблемы и мне совершенно плевать какими функциями эти решение будет вызываться. Единственное что хотелось бы, так это чтобы число функций было не больше одной, а объекты как таковые мне не нужны.

>в очень узком сегменте создания интерфейсов в основном графических, но и на С есть примеры превосходной функциональности и качества

ээээ. а вы программировали на си в этих "примерах"? и в других на с++? и где удобнее, проще и логичнее? (если оба пути не пробовали - можете не отвечать, и так все ясно)

>Мне не нужна потенциальная возможность - мне как пользователю нужно рабочее решение моей проблемы и мне совершенно плевать какими функциями эти решение будет вызываться.

в чистом виде вантуз-way. ничего личного

В результате лет через несколько получится неуправляемый монстр, поскольку автор уже забудет что делали те или иные куски. Это я видел в личной практике.

Между прочим почитайте, Страуструпа, он пишет что С++ появился в основном по причине, что реализация сложных проектов автоматизации в промышленности на С стала невозможно из-за чудовищной сложности кода, потребовался переход на более высокие уровни абстракции.

> ээээ. а вы программировали на си в этих "примерах"? и в других на с++? и где удобнее, проще и логичнее? (если оба пути не пробовали - можете не отвечать, и так все ясно)

По мне так Motif понятнее и удобнее чем более другие библиотеки.

>>Мне не нужна потенциальная возможность - мне как пользователю нужно рабочее решение моей проблемы и мне совершенно плевать какими функциями эти решение будет вызываться.

>в чистом виде вантуз-way. ничего личного

Вы элементарно не правы. Это и есть Unix-way - составление последовательных решений в цепочку. В каком месте там объекты?

> Между прочим почитайте, Страуструпа, он пишет что С++ появился в основном по причине, что реализация сложных проектов автоматизации в промышленности на С стала невозможно из-за чудовищной сложности кода, потребовался переход на более высокие уровни абстракции.

В реальности работать с абстракциями высокого уровня не получается, так как постоянно выясняется, что на самом нижнем уровне не так что-то описали и всё идёт просто на слом. Для тех систем, где объекты являются естественным - aka GUI-интерефейс это работает замечательно, а вот там где приходится соприкасаться с жизнью с её постоянно меняющимся ТЗ на нижнем уровне такой подход просто не применим.

P.S. Страустропа читал - не впечатлил.

лучше скажите , как этого зверя (spss) попробовать -
trial, demo, ворованная - у кого-нибудь есть?

весь мало мальский научный софт "за деньги" мертвенький ;(

для желающих убедится попробуйте посмотреть что с khorus сдучилось, если следы найти удастся. последнее что нашел я его как компоненты для какой то виндовой байды продали козлищи закрывшие код.

здесь просто почувствовали что еще немного, и R вынесет с рынка все что еще шевелится.

кстате статграфикс тоже все возможности имел и без открытости слил.

Если пойти против традиций LOR и сходить по ссылке, то можно быстро найти 14дневный trial, правда, как я понял, под альтернативную систему.

> весь мало мальский научный софт "за деньги" мертвенький ;(

Не весь, например, Mathematica пока ещё активно живёт и развивается. Её ещё долго догонять надо.

> Для тех систем, где объекты являются естественным - aka GUI-интерефейс

Ну почему сразу GUI? А как же VFS в ядре например? А файл в UNIX, который может быть каналом,обычным файлом или устройством и ко всему этому существует одинаковый интерфейс (open/read/write)? ООП -- это очень полезный подход, плохо, когда ООП превращается в навязчивую идею, как в C++ например.И вообще, ООП != С++.

> и сходить по ссылке,

по ссылке, есен пень, ходил -> потому и задал вопрос

На главной странице справа чуть ниже середины есть возможность попасть в раздел где раздаются спецификации и информация о возможностях, а так же триалы.