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

[macroevolution]

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

Comments

[bear-bull.livejournal.com]

Тут уж либо простенький язык - тогда за тебя все будет делать комп - и медленно естественно, либо - все делать самому на каком-нить С++ - тогда может получиться быстро.
Как вариант - VB под тем же Access, но не использовать все эти медленные sql-запросы, а занести все данные в массивы и самому с ними работать. Мне кажется, так будет быстрее.

[arech]

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

[bear-bull.livejournal.com]

понятно это - поэтому и привел в пример 2 противоположных полюса

[firrior.livejournal.com]

"все эти медленные sql-запросы" по определению быстрее, чем запись в массивы. Одно дело оптимизация дилетанта, другое - профессионалов-оптимизаторов, писавших SQL-движок.

[bear-bull.livejournal.com]

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

[vmenshov.livejournal.com]

Одно дело - чтение с диска, совсем другое - работа с оперативной памятью.

[firrior.livejournal.com]

Разве? А дисковый кэш в ОС зачем?

[lvqcl.livejournal.com]

"для имитационного моделирования эволюционных процессов в популяциях"? Незачем, скорее всего.

[vmenshov.livejournal.com]

Дисковый кэш живет свой жизнью, и гарантий, что там есть нужные данные никто не дает. Кроме того, в винде работа дискового кэша регулируется функциями win api. Стандартные процедуры аксеса и могут его вообще отключить при чтении своих данных.

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

И это все только в случае с чтением.

Если же начинается запись, то все, привет.

[http://users.livejournal.com/_ddd_/]

Один select с полной выборкой и занесением ее в массив на порядок быстрее, чем дерганье базы по каждому запросу, особенно если база большая. Даже занесение выборки в одну строковую переменную и последующий instr по ней (до известных пределов, конечно) будет шустрее.
Работа же с массивом по определению намного быстрее, чем обращения к БД.

Занимаюсь парсингом, размеры БД достигают десятков миллионов записей, и если по каждому чиху делать sql-запрос, то обработка будет идти годами. Правда, с массивами таких масштабов другая проблема - можно вылететь в какой-нибудь out of memory, но это решаемо.

[maz-d.livejournal.com]

/Один select с полной выборкой и занесением ее в массив на порядок быстрее/

если конечно не надо делать 14 джоинов =)

[sumerk.livejournal.com]

Очень правильный подход.