Посоветуйте язык программирования

[macroevolution]

Я всю жизнь программировал только на бейсике, на разных его версиях.  Так получилось. Когда писал кандидатскую, набралось очень много таблиц с данными (это были морфологические признаки морских ежей), и я задолбался обсчитывать их на калькуляторе. Поэтому быстренько освоил бейсик (тогда персональные компьютеры IBM только начали появляться, и к ним прилагался язык GW-Basic). Освоил - и сразу почувствовал себя человеком. С тех пор не переучивался, сейчас пишу все свои программки на VBA в MS Access. То есть в программировании я дилетант, но опытный. Программированием пользуюсь сейчас для имитационного моделирования эволюционных процессов в популяциях. Подумываю об одной новой модели, но понимаю, что на VBA она будет работать невыносимо медленно. Насколько я понимаю, программа, написанная почти на любом другом языке, компилируемом, будет работать в разы быстрее. Вопрос такой: какой из этих языков мне будет быстрее и проще всего освоить? Времени, сил и желания преодолевать трудности и вникать в программистские проблемы - не имеется. Мне бы этот язык просто скачать (можно купить, если не слишком дорого), освоить за пару-тройку дней - и вперед. Т.е. главное, чтобы он был максимально простым в освоении для того, кто знает бейсик, без всяких интеллектуальных "понтов", но работал хотя бы раз в 10 быстрее.

Comments

[pssshik.livejournal.com]

Ну память нынче очень дешевая - это не проблема (смотрю на жаба веб сервер с 45 гб выделенной под него памяти). Жаба просто не приспособлена для научных расчетов - ну не удобно создавать самому всю инфраструктуру, ввод и вывод - в жабе нет по умолчанию даже комплексных векторов и матриц, библиотеки, которые с ними работают - какие-то дикие. Еще минус - сверхжесткая типизация: описывать каждую финтифлюшку как отдельный класс, делать дерево наследования, чтобы использовать один метод для разных классов - та еще забава.

Таким образом есть страшный и ужасный фортран - это набор библиотек + привычка науч сотрудников, корявый (личное оценочное суждение) питон - как простенький язык с низкими требованиями к освоению, и спец пакеты - если человек 20 лет пользовался математикой или матлабом, пересесть на что-то другое ему будет очень сложно.

[agalakhov.livejournal.com]

Питон не коряв, он просто очень непривычен. С практической точки зрения он как раз очень удачный - очень мало языковых сущностей, практически все является просто синтаксическим сахаром поверх пары простейших внутренних операций, и за счет этого можно очень быстро писать очень сложные вещи. (Мой личный рекорд - полноценный работающий транслятор PHP-подобного языка, написанный с нуля за 40 минут).

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

[agalakhov.livejournal.com]

А память я бы не стал считать "не проблемой". Научные расчеты всегда упирались как раз в память. Большинство практических задач по памяти имеют O(n^2) или O(n^3), поэтому удвоение и даже учетверение памяти - это слону дробина. Я помню, на 256 мегабайтах мы могли едва-едва делать расчет для 20 атомов, а реально хотелось бы для нескольких тысяч. Для таких вещей и терабайта не хватить может. Поэтому приходится очень аккуратно оптимизировать расход памяти: экономия пары байтов в структуре, которая создается миллиард раз - вот уже и пару гигабайт сэкономили.

В обработке больших данных, которой я тоже позаниматься успел, та же петрушка. Когда база весит около 100 гигов и когда стремишься засосать в ОЗУ максимум, сколько туда вообще влезет, чтобы не прыгать головкой по диску, считать память начинаешь тоже уже очень аккуратно. 16 гигов на один массив, 16 гигов на другой, и следишь, чтобы все это объем физической памяти не превысило, а то улетишь в своп.

[pssshik.livejournal.com]

ну база на 100 гигов - это фигня, если честно, т.к. можно в сервер и 128гигов набить. если нужно рандомное чтение-запись - ну ссд диски уже вовсю используются. расчитывать терабайт на одном серваке - ну это неэффективно уже по процессорным мощностям, так что терабайт вычислений будет раскидан по 5-10 машинам, что реально уже сейчас, а завтра будет просто общим местом. Проблема обьект-спамминга (когда на простую операцию создается класс обертка, несущий в себе класс, который является посредником для общения с другим классом, а потом передается другому свежесозданному классу,... ) в яве стоит остро, но это уже уровень программиста.

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

[agalakhov.livejournal.com]

> ну база на 100 гигов - это фигня, если честно, т.к. можно в сервер и 128гигов набить.

Если база ОБРАБАТЫВАЕТСЯ, то для промежуточных результатов и словарей требуется ОЗУ, в несколько раз превышающее объем базы. Практически при 128 гигабайтах памяти предел объема базы, при котором такая обработка еще эффективна, составляет 30-40 гигабайт. Если надо больше, то обработку приходится делать уже оффлайн, на дисковых файлах и не в реальном времени.

> ООП эффективно для задач, которые легко представляются в виде диаграммы обьекты-акторы-действия

Но в таких задачах уже вовсе необязательно делать ООП на уровне языка, достаточно на уровне библиотек. ООП создавалось как раз для решения таких задач (Smalltalk), но потом были придуманы методы поинтереснее и с меньшим количеством подобных эффектов.

[akheront.livejournal.com]

Память дешёвая была летом. Сейчас кусается.

[pssshik.livejournal.com]

Память кусалась пять (10, 15) лет назад - сейчас дешевая и будет только дешеветь :)

[akheront.livejournal.com]

Да что вы говорите. Валюта дорожает, а память дешеветь станет? Она же импортная вся.