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

[macroevolution]

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

Comments

[daeloce.livejournal.com]

"Именно поэтому асемблер и работает априори быстрее всех"

Распространенное заблуждение оставшееся от 90х годов. Сейчас вы никогда, как бы круты ни были, не напишете на асме быстрее чем на Си. Просто потому, что компиляторы достигли такого уровня развития, что способны просчитать и предсказать огромное количество мест критичных для скорости и с оптимизировать их. Вы же никогда не сможете в более менее сложном случае учесть даже все RAW, WAR и WAW конфликты, не говоря уже о толковом разворачивании циклов, предсказании ветвлений и прочем.

[daeloce.livejournal.com]

"Там часто java ровно на том же уровне что и C++"

Тут от задач зависит. В ряде случаев java или C#, даже быстрее плюсов могут оказаться, ибо GC не только мусор подчищает, я бы даже сказал не столько, но и память оптимизирует, что в определенных случаях может дать выигрыш по сравнению с чистым unmanaged кодом. Но, чтобы так писать надо а) - очень глубоко знать архитектуру компа, причем желательно целевого на котором будет работать код, и б) - очень аккуратно и скурпулезно писать код, но при этом все достоинства java, а именно лаконичный, красивый и понятный код, исчезают бесследно и оказывается проще это написать на сях или плюсах.

[kallbasser.livejournal.com]

Если вы читали ветку и дочитали до конца, то должны заметить, что речь была только о с потолка взятом двукратном приросте производительности на плюсах. Очевидно, что код написанный на C++ при должном умении, будет быстрее чем Java. Если вопрос с производительностью стоит остро, то C++ без вариантов. Но, это, в свою очередь, и от программиста требует больших усилий. Из поста неочевидно, насколько это нужно. Java и C# при низком пороге входа покажут лучшую производительность по сравнению с VB6

[jr0.livejournal.com]

Задача - расчеты и их скорость. Это не то, что делают современные системы программирования.

Mathcad для расчетов и их проверки.

[martin-222.livejournal.com]

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

[wormball.livejournal.com]

Э, батенька. Интерпретатор - великая вещь, позволяет писать программу и одновременно отлаживать её со скоростью мысли. Просто в массовом сознании интерпретаторы были знатно дискредитированы собственно бейсиком. Точнее, не столько им, сколько контрастом между тем, что "было" (компьютеры наподобие БК-0010 с голым бейсиком, где всё надо было забивать ручками) и тем, что "стало" (писюки с виндой, где все нужные массовому пользователю программы вроде как уже написаны).

[jr0.livejournal.com]

Эти сомнения разрешит только опыт. То есть только автор, если пожелает. Испытания просты, в этом суть.

Вы считали численно? И там есть возможность добавить свой способ интегрирования. Я смог.

[techwork.livejournal.com]

начнём с того что сейчас объёмы программ гигантские - от сюда и ваша проблема. Это не проблема скорости работы ассемблера - это проблема скорости разработки."не неучтёте" а " не хватит времени" и позор для математика этого не знать. Учесть можно всё - вопрос лишь в количестве человекочасов на это.

[martin-222.livejournal.com]

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

[jr0.livejournal.com]

Приведите интеграл, если не лень.

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

[natvalbr.livejournal.com]

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

ну, если у вас есть текс, то простым поиском подстроки "inet addr:" можно получить искомую информацию. Посмотрите информацию о "поиск подстроки в строке".

[jora0.livejournal.com]

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

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

[jora0.livejournal.com]

Имеется ввиду чистый С ?
Я его, помнится, в институте изучал. Хороший язык. Но как сейчас с компиляторами/интерпретаторами? Выше вон, пишут, что C++ требует других методов работы, и тупо компилировать программку для С на компилляторе для С++ опасно.

[martin-222.livejournal.com]

Интеграл не смогу привести, так как это было в студенческие годы, а сейчас не студент и интеграла не помню. Помню, что у него были проблемы чтобы посчитать некоторые интегралы, которые дают в итоге арктангенс. Если в знаменателе интегрального выражения есть корень из минус единицы (или нам нужно ввести мнимую единицу для подсчета интеграла), то тут у него проблемы были с подсчетом.

[jr0.livejournal.com]

То есть аналитика? Этого вообще нет в других системах.

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

[twi1ightsparkle.livejournal.com]

не могу осилить over 600 комментариев.
при случае напишите, что выбрали - очень интересно!

[martin-222.livejournal.com]

Как я понимаю А.Маркову и ненужна аналитика. Или нужна?

[daeloce.livejournal.com]

"от сюда и ваша проблема"

У меня проблем нету :)

А если серьезно, то не отсюда. Дело не в гигантских программах. Дело в умных компиляторах. Раньше компиляторы были довольно примитивные, и с трудом справлялись с одной лишь компиляцией, и тогда действительно, переписав критичный кусок кода на ассемблере можно было его ускорить на порядки. Но те "счастливые" времена прошли. Для сведения, интеловский компилятор, ЕМНИП при оптимизации оценивает код окном в 500 комманд, т.е. он оценивает зависимости по данным, регистрам и прочему для 500 команд одновременно. И да, при оценке кода он по нему, по коду проходит около 100 раз. Вы способны это сделать? Вы способны предсказать ветвления для всех условных операторов? А развернуть каждый цикл, прооптимизировав при этом его?

"Это не проблема скорости работы ассемблера"

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

""не неучтёте" а " не хватит времени" и позор для математика этого не знать"

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

В общем, к чему я это все. Писать на асме для HPC в настоящее время глупость. Асм нужен в двух моментах: микроконтроллеры, где часто очень мало оперативной и флэш памяти(нормальное явление когда там 256-512 байт ОЗУ, и пару кБ флэша), хотя тут тоже можно обойтись С, но все же иногда ручное написание кода на асме даст немного более компактный код. Второе использование асма, это оценка узких мест в том же HPC, т.е. ты смотришь на ассемблерный листинг который сгенерировал компилятор, понимаешь почему это работает медленно, и меняешь код на С. Третий случай тоже есть, но общая доля много меньше процента. Это тот случай когда действительно выгоднее написать маленький кусок кода на асме - в особо специфических случаях ты действительно сможешь написать немного более быстрый код, чем сгенерирует компилятор, исключительно за счет своих априори знаний о предполагаемой работе алгоритма. Но повторюсь, таких случае ничтожно мало, и с развитием компиляторов их становится еще меньше.

[techwork.livejournal.com]

блин да что вы всё сводите к одному человеку ? И вы так ведь и не опровергли то что это вопрос лишь времени или интуиции - подбор идеальной последовательности.
А какой бы не был анализ заданный другим алгоритмом - он всегда будет следовать алгоритму. То есть форме при создании которой все возможные вариации создававший его человек также учесть не смог. Потому что иначе любую оптимальную программу можно было бы предсказать.

[jr0.livejournal.com]

Вопрос ни к чему. Аналитика это хорошо.

[pusk1.livejournal.com]

Просто смена языка даст прирост порядка 20% или не даст вовсе.
Рекомендую взять в помощники толкового студента, разбирающегося в IT, проконсультироваться с профессионалами.
Другой путь - найти готовую библиотеку, которая обеспечит нужный вам функционал.
Третий путь - разобраться в параллельных вычислениях. Но это не за 3 дня.
Нужно краткое описание модели и кусок кода, если есть. Обычно сильно тормозит небольшой фрагмент программы. Причина может быть не в языке, а в обращении к базе данных, например. Часто бывает, что без смены языка получается увеличить быстродействие на 1-3 порядка. Если вы постоянно обращаетесь к данным в в MS Access при моделировании, то прирост на пару порядков легко достижим без смены языка.

[nemo2015.livejournal.com]

macroevolution писал "Я точно знаю, что мне нужно, и вопрос сформулировал оптимальным образом."
Тогда можно сделать вывод , что нужен был такой себе холивар на тему какой язык программирования лучше. :) Вяло текущая версия уже имеется, но буйных пока мало.

Если серьезно, то проще перейти на Visual Basic 6.0 (без А), что и советовали выше, там будет компиляция, а освоить нужно в основном среду программирования.
Есть еще такой зверь KBasic( https://ru.wikipedia.org/wiki/KBasic), 30 евро за проф версию с компилятором, есть условно-бесплатные версии.
А если еще серьезнее, то нужно понять в чем проблема низкого быстродействия.
Зачем вы используете VBA в Access? Данные хранятся в БД? Тогда очень сильно может влиять
доступ к БД, стиль обращения и формат хранения данных. А может реляционные БД не подходят для вашей задачи?
Нужна конкретика.
Об этом несколько человек пишет (например, хороший пост romikchef ). Но конкретики нет. Сколько особей в популяции, сколько параметров (генов) у особи? Особь "живет" /меняется (и это тоже надо моделировать)? Как происходит модификация генов?

Инструмент выбирают по задаче ( а ее здесь не видно), а иначе я выбираю этот млоток, потому , что у него красивая ручка или "Дайте эти пассатижи от фирмы MS, они очень модны в этом сезоне."

[nemo2015.livejournal.com]

Ну тут не просто смена языка, а переход от интерпритатора к компиляции, так, что можно намного больше 20% выиграть.
Библиотеки в явном виде тут нет, автор видимо планирует научное исследование. Но это не значит, что нет эффективной библиотеки реализующей необходимую математику. А какая она нужна - загадка покрытая мраком.
А в остальном абсолютно поддерживаю.

[sumerk.livejournal.com]

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

[sumerk.livejournal.com]

Да, живой Дельфи, я на нем пишу.
Нет, дельфи ученому не годится категорически.