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

[macroevolution]

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

Comments

[bougakov.livejournal.com]

Всё равно learning curve куда как короче, чем при перескакивании с VB на тот же Python. Интенсивное гугление, копипейст из найденных кусков кода - и в очень короткие сроки имеем уродливый кусок кода, который, тем не менее, работает.

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

P.S. Вдруг сообразил, что никто не предложил старый "полноценный" Visual Basic 6.0 - http://rutracker.org/forum/viewtopic.php?t=2514447 Синтаксис идентичен синтаксису VBA - т.е. переучиваться не надо, работать будет однозначно быстрее. Чем не вариант?

[lvqcl.livejournal.com]

>Чем не вариант?

Варез. Может не пойти по лицензионным соображениям.

[arech]

1) быстрее, но не намного
2) либо невозможна, либо дико геморно распараллеливание вычислений, что скорее всего крайне необходимо в предметной области
3) в целом продукт мёртв. Инвестирование времени на переход в него и наращивание кодовой базы скорее всего останутся убыточными, т.к. в будущем всё равно придётся соскакивать с него на что-то более адекватное.
Не надо, это тупик.