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

[macroevolution]

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

Comments

[shilliennv.livejournal.com]

А разве не было у вас уже такого поста (или я вас с кем-то похожим путаю).

Думаю, тут стоит пойти таким простым путем: язык программирования взять любой, например, вспоминая свои первые опыты с языками, по возрастанию сложности я бы их расставила так: php, pascal/Delphi, java, C/C++, python. php исключаем из-за его специфической ориентированности, из остальных можно выбирать. Второй шаг для простого пути - найти человека, который на пальцах объяснил основы и применение именно в ваших задачах.

Я бы остановила выбор именно на Pascal/Delphi из-за удобного визуального интерфейса среды и отличной системы помощи и всплывающих подсказок.

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

[agalakhov.livejournal.com]

Лучше не надо Pascal.

Если расставлять языки по их РЕАЛЬНОЙ сложности (за "сложность" принимать среднее количество грубых ошибок при программировании на одну страницу кода), то расклад получается совсем иным:

Python - простейший, затем классический Pascal, C, Ruby, Java, C++, PHP, Delphi - самый сложный.

Почему так. Потому что модель управления памятью в Delphi провоцирует вполне определенный класс ошибок, связанных с неправильным удалением объектов после их создания. Точно так же система типов в PHP провоцирует совершенно определенный класс ошибок, связанных с неверным приведением типов переменных. И то, и другое абсолютно сводит на нет кажущуюся "простоту" языка. Практически все начинающие и многие "опытные" разработчики пишут на этих языках неправильно.

Классический Pascal (вариант Никлауса Вирта) от этой проблемы свободен, но доступной среды для классического Pascal не существует. Есть только Delphi. Язык C довольно прост - его трудно понять в первые дни из-за указателей, но зато там кроме указателей вообще никаких сложностей нет. C++ сложнее намного, там опять вылезают ошибки в работе с памятью (применение приемов из C к С++ недопустимо и приводит к катастрофе). Поэтому Java стоит между ними - сложнее C, но проще C++.

[shilliennv.livejournal.com]

Питон у меня был шестым языком, не считая всяких встроенных скриптовых языков типа Action Script, и он мне дался очень тяжело. Так что тут я с вами не соглашусь ) Автору поста вряд ли нужно писать сложные программы с учетом расхода памяти и потоков, как я поняла, речь идет о несложных с точки зрения программирования, но ресурсоемких при выполнении расчетах, так что вряд ли то, о чем вы пишете, будет играть существенную роль. Проще говоря, даже написаная "неправильно" с вашей точки зрения программа будет вполне справляться со своей задачей ) А такую "неправильную" программу в Delphi написать будет просто и быстро - какова и была поставленная задача.

[agalakhov.livejournal.com]

"Неправильная" программа - это программа, которая НЕ ВСЕГДА дает правильный результат работы. Это бывает намного хуже, чем программа с очевидной ошибкой. Такой программой можно что-нибудь посчитать, получить неверное число и этому числу поверить. Отладке такое не поддается, вероятность заметить ошибку исключительно низка.

На Delphi и PHP вероятность написать такую программу очень велика. На языках вроде Ada она практически равна нулю. На C и Python она есть, но приемлемо низка.

[shilliennv.livejournal.com]

Опять же, все зависит от сложности вычислений. Вы же не будете утверждать, что написанный на Delphi калькулятор будет временами показывать, что 2+2 равно пяти? Поэтому я и уточнила в первом комментарии, что для более конкретных советов нужно иметь представление об уровне задачи. Не стоит усложнять простые вещи.

[agalakhov.livejournal.com]

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

Написанный на Delphi калькулятор как раз МОЖЕТ время от времени показывать, что 2+2 равно пяти, если сделана одна определенная, очень характерная именно для Delphi ошибка: объект уничтожен в неправильном месте (слишком рано). При этом в памяти обычно все еще сохраняется "правильное" содержимое объекта, и программа "продолжает работать". Но иногда, довольно редко, везение кончается, и программа выдает неверный ответ.

Речь именно о том, что на Delphi программа с явной ошибкой может ЧУДОМ работать правильно в 99% случаев. На большинстве других языков программа с такой ошибкой не работала бы совсем, и ошибка была бы сразу найдена.

Причина: в Delphi "улучшили" Pascal. В оригинальном паскале была четкая синтаксическая разница между объектом и указателем. В Delphi "для удобства" указатели на объекты замаскировали: когда программист создает объект, он на самом деле получает указатель, но этот указатель ведет себя как объект (обращения к полям делаются через точку, а не через крыж-точку, как в Паскале, и так далее). Из-за этого программист часто делает операцию вроде копирования с указателем, думая, что работает с объектом. И часто удаляет единственный экземпляр объекта, думая, что удаляет ненужную копию. Но при этом указатели продолжают оставаться доступными. Обратившись по ним, часто можно получить вполне правильный результат, как если бы объект все еще существовал.

[shilliennv.livejournal.com]

Дело как раз в том, что необязательно забираться в такие дебри для решения указанных автором задач, если уж на VBA все это было реализовано и работало верно.

[yva.livejournal.com]

Пардон, но почти всё написанное - полная ерунда.

[pssshik.livejournal.com]

жаба намного проще и си и си++ так как управление памятью отдано гц. А какие-такие фокусы из си в си++ вызывают ошибки?

[agalakhov.livejournal.com]

На C++ типичная ошибка - это написать пару malloc+free или new+delete. Это нормальная техника в Си, но недопустимо в языках, поддерживающих исключения. Потому что исключение перепрыгивает delete. Следует использовать unique_ptr или shared_ptr. И здесь есть еще отдельная пакость в использовании переменной после delete, потому что с большой вероятностью лежит она все еще в нашем адресном пространстве и даже может все еще иметь прошлое значение. Получается программа, которая ОБЫЧНО работает (ведь с вероятностью 99% переменная все еще имеет верное значение!), но время от времени жестоко глючит. И если программист не имеет представления об инструментах вроде Electric Fence, то из-за такого кода он рискует оказаться в глубокой заднице.

Другая типичная ошибка - забывать слово const и использовать string вместо const string&, а еще злоупотреблять присваиванием строк. Хотя это работает, это работает кошмарно медленно и жрет очень много памяти. В глубоком цикле такая ошибка может привести к высвоповыванию или даже к срабатыванию OOM killer, не говоря уж о том, что из-за этого жалкие несколько килобайт текста могут обрабатываться несколько минут.

На Java и других GC-языках тоже есть типичная ошибка - делать у объектов слишком большое время жизни. Из-за того, что объект не надо удалять, программист слабо следит за тем, в какой именно области видимости объект создан. В результате ссылка на объект может жить в сотни раз дольше, чем реально надо, и память забивается такими вот "вроде бы нужными" объектами, которые GC не удаляет, потому что формально они еще используются. Обычно это бывает, если программист ленится передавать переменную через параметры функции и потому делает переменную членом класса. Такая практика - вообще очень большое зло, но на языках без GC программист очень быстро получает по лбу граблями от деструктора этой переменной и перестает так делать, а на языках с GC можно писать так годами и не понимать, почему это плохо.

[guga50.livejournal.com]

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

не понял, если честно. это как?

[agalakhov.livejournal.com]

Это когда человек, вместо того, чтобы написать примерно так:

int x = 5;
f1(x);
f2(x);

делает переменную x членом класса и пишет примерно так:

this.x = 5;
f1();
f2();

В результате переменная x уничтожается гораздо позже, чем это реально требуется по логике кода. И обычно, увы, это вовсе не int, а некий довольно тяжелый объект класса.

[guga50.livejournal.com]

это я понял. как по жопе граблями получить в смысле по лбу я не понял.

[psilogic.livejournal.com]

отвечу за вашего собеседника

1. пусть есть временная переменная tmp, ей что-то присвоено

2. ссылку на эту переменную отдают какому-то долгоживущему объекту obj, прикапывают в каком-нибудь его поле obj.member

3. мы выходим из области видимости для tmp
на этом шаге в языке без GC tmp уничтожается
на этом шаге в языке с GC tmp остается т.к. на него есть ссылка из obj

4. мы пытаемся использовать obj.member
на этом шаге в языке без GC возможен краш
на этом шаге в языке с GC краша не будет, но будет обращение к вроде как валидному объекту, который давно не нужен и, скорее всего, никак не соответствует происходящему

[agalakhov.livejournal.com]

Кстати, для вычислительных алгоритмов над большими массивами языки с чистым GC (вроде java) имеют очень спорную пригодность именно из-за склонности GC освобождать память слишком поздно. Когда вычисления и так требуют гигабайты (а для решения уравнений, сводящихся к диагонализации матриц, это не редкость), дополнительный расход от опоздания GC часто становится фатальным и приводит к тому, что программа вообще не работает на данном железе. Именно поэтому программы для научных расчетов крайне редко пишутся на Java, чаще используются Fortran и Python, чуть реже C.

[pssshik.livejournal.com]

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

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

[agalakhov.livejournal.com]

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

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

[agalakhov.livejournal.com]

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

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

[akheront.livejournal.com]

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

[chebudzee.livejournal.com]

Что за бред? В питоне тоже есть GC и оно работает гораздо медленне чем java.

[agalakhov.livejournal.com]

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

К тормозам Питона GC отношения вообще не имеет. Все дело в том, что РЕФЕРЕНСНАЯ (и только референсная!!!) реализация Питона - так называемый CPython - это чистый интерпретатор. В нем нет JIT совсем-совсем. Поэтому он, как все чистые интерпретаторы, очень медленный: ему каждую переменную приходится искать в памяти ПО ИМЕНИ, в худшем случае за O(log(N)). К другим реализациям питона это не относится. В частности, PyPy - это JIT, и на тестах арифметики он по производительности ПРЕВОСХОДИТ Java, иногда процентов на двадцать. Во многом именно за счет того, что счет ссылок, в отличие от GC, поддается частичному развертыванию на compile-time (см., например, Ахо, Сети, Ульман, "Компиляторы: принципы, технологии, инструменты", главы 7 и 12 по 2-му изданию).

Что касается NumPy для вычислений, то NumPy даже в CPython работает с максимальной возможной скоростью, ибо написан на Си, местами с оптимизацией на ассемблере. Он быстрее даже фортрана.

[zelych.livejournal.com]

> А разве не было у вас уже такого поста (или я вас с кем-то похожим путаю).

У progenes был http://progenes.livejournal.com/250141.html

[shilliennv.livejournal.com]

Извиняюсь тогда.

[lvqcl.livejournal.com]

Цитата оттуда:
"У нас есть база данных, которая даже вполне в екселе. Но оболочку для визуализации и сортирования (если я правильно выражаюсь) программист соорудил в Phyton (если я правильно выражаюсь). Не факт, что это оптимальное решение. Есть основания полагать, что не оптимальное, но кроме него никто не разбирается. Я хочу разобраться, как это работает."

Хм.

[zelych.livejournal.com]

Хм.