macroevolution (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
macroevolution) wrote2015-01-11 02:41 pm
macroevolution) wrote2015-01-11 02:41 pm
Посоветуйте язык программирования
Я всю жизнь программировал только на бейсике, на разных его версиях. Так получилось. Когда писал кандидатскую, набралось очень много таблиц с данными (это были морфологические признаки морских ежей), и я задолбался обсчитывать их на калькуляторе. Поэтому быстренько освоил бейсик (тогда персональные компьютеры IBM только начали появляться, и к ним прилагался язык GW-Basic). Освоил - и сразу почувствовал себя человеком. С тех пор не переучивался, сейчас пишу все свои программки на VBA в MS Access. То есть в программировании я дилетант, но опытный. Программированием пользуюсь сейчас для имитационного моделирования эволюционных процессов в популяциях. Подумываю об одной новой модели, но понимаю, что на VBA она будет работать невыносимо медленно. Насколько я понимаю, программа, написанная почти на любом другом языке, компилируемом, будет работать в разы быстрее. Вопрос такой: какой из этих языков мне будет быстрее и проще всего освоить? Времени, сил и желания преодолевать трудности и вникать в программистские проблемы - не имеется. Мне бы этот язык просто скачать (можно купить, если не слишком дорого), освоить за пару-тройку дней - и вперед. Т.е. главное, чтобы он был максимально простым в освоении для того, кто знает бейсик, без всяких интеллектуальных "понтов", но работал хотя бы раз в 10 быстрее.
no subject
С бейсика соскочить на другой язык программирования совсем быстро и просто не получится, если это единственный язык, который вы знаете.
По любому прийдется затратить усилия и время.
>освоить за пару-тройку дней - и вперед
Этого не выйдет, пару недель - еще куда не шло. И это лишь для того, чтобы научиться хорошо делать то же, что делали на Basic.
К тому же такой критерий, как скорость работы программы... Хотя у бейсика и есть определенные проблемы с производительностью, но переход к быстро изучаемым языкам может не дать желаемых "10 раз быстрее". Перейдя на то же Python в случае вычислительных задач этих 10 раз не получить. И да, Python не компилируемый язык.
У языков программирования разные пороги вхождения и разные возможности, разные доступные библиотеки.
Тот же C имеет довольно высокий порог вхождения, на нем очень просто делать ошибки, которые потом приходится героически вылавливать днями, неделями, месяцами, но опытный программист может в некоторых случаях для вычислений задействовать GPU (видеокарту), и по сравнению с бейсиком здесь может быть и в 1000 раз быстрее, и даже более. Но если вы решите попробовать C после бейсика, то вы просто потратите напрасно время из за этого самого порога вхождения - чтобы достичь нужного уровня (сносного) на C, программированием нужно заниматься профессионально.
Если давать рекомендацию "от балды" (а по вашей постановке задачи я, несмотря на свой более чем 20-ти летний опыт профессионального программирования, могу только так и поступить), то я бы сказал:
- R как специализированный язык для статистической обработки данных
- Java как универсальный язык программирования
- Python как язык, на который быстрее всего можно соскочить с бейсика
За пару недель сможете освоить не хуже бейсика эти языки
Но это все равно, что абстрактному человеку ответить на вопрос "какую машину мне купить?" имея на входе только информацию "чтобы коробка автомат была".
Если хотите более взвешенных рекомендаций, попробуйте описать, с какими данными вам обычно приходится работать и как эти данные обрабатываются, а так же что обычно хотите получить на выходе.
Данными на входе могут быть как гига и даже терабайтные массивы, так и небольшие векторы. У данных обычно бывает тип.
Обработка может представлять из себя как огромное число циклов с одними и теми же данными, так и вычисление чего-то в на основе данных из огромных таблиц.
На выходе может быть достаточно вывода текстового результата в консоль, а может потребоваться нарисовать графиков с рюшечками.
Вы можете потратить сейчас время на изучение языка, а потом понять, что для ваших задач вы ничего не выиграли по сравнению с бейсиком.
no subject
С - очень простой язык. С++ - другое дело. Да и вообще. Язык это только набор средств. Нет сложных языков, есть сложно написанные программы.
no subject
Лаконичность синтаксиса языка еще не означает, что язык простой.
У того же brainfuck весь синтаксис - 8 символов-команд, но много людей, которые пишут только на Basic, смогут написать на brainfuck хоть что-то осмысленное и оптимальное за пару дней (тот же "Hellow, word!\n")? А для профи освоить этот язык до сносного уровня - пол часа на пощупать. А в лоб плюсами, минусами и точками, он "Hellow, word!\n" за 10 минут слабает, из которых 8 уйдет на подсчет плюсов и минусов.
Тот же C при работе с массивами данных не может обойтись без указателей, а работа с ними для пришедшего из Basic "опытного дилетанта" - это не реально. Не стоит даже пытаться.
C - это язык для профессиональных программистов, и то только для решения узкого круга задач. Да, на нем можно написать что угодно. Ну так я и на ассемблере в теории могу написать что угодно (при наличии неограниченных ресурсов для написания этого чего угодно). Но только я не буду что угодно на нем писать.
no subject
Тем более его никто не заставляет ими пользоваться.
no subject
>понять что у переменной адрес в памяти есть?
От того, что вы поймете, что есть адрес, вам легче нисколечко не станет.
Так как вам прийдется этими указателями управлять. Кроме просто понятия адреса есть стек и хип, к примеру. И если вы возвращаете из функции указатель на массив, созданной в ней на стеке, то вызывающий код будет неприятно удивлен тем, что он получит. При этом у него есть неплохой шанс удивиться не сразу, так как есть далеко ненулевая вероятность того, что в одном месте функция будет работать без последующего сваливания, а в другом вы будете получать полную лабуду. И будете гадать, в чем проблема - в коде, который функцию вызывает, или в самой функции.
>Тем более его никто не заставляет ими пользоваться.
Как и сам язык :)
no subject
В си и си++ - куда поклали - там и возьмёте
в С# об описанной опасности прямо говориться в доках.
no subject
Нет, потому что вы имеете не один способ не найти где-то того, что ожидаете.
Возврат указателя на стек, free, оказавшийся на одну закрывающуюся фигурную скобку выше, чем того хотелось бы, ошибки разыменовывания указателей, когда вы думаете, что меняете данные в одном массиве, а на самом деле меняете все, что угодно, но только не то, что нужно. И когда вам понадобилось это "все, что угодно", то там оказывается не то, что вам нужно.
no subject
>>Тот же C при работе с массивами данных не может обойтись без указателей, а работа с ними для пришедшего из Basic "опытного дилетанта" - это не реально.
Я говорю что реально. Да если вы лезете в дебри, мутите списки и прочее - то уж это ваши проблемы. Просто тупо аллокейтить памяти для данных в си - это совсем не сложно. Ни для кого.
no subject
Ну да :) Не сложно. malloc, calloc, free...
И большинство ошибок в программах на C и C++ связанны с указателями, с такой простой вещью.
Потому что одно дело "знать об адресе" и о malloc/free, а другое дело управлять всем зоопарком указателей, который к алгоритму никакого отношения не имеет.
И ладно еще, если ошибка приводит к немедленному сваливанию программы (что бывает далеко не всегда). Нередко все приводит к тому, что вы сталкиваетесь с неожиданными данными в неожиданном месте всего лишь потому, что где-то (как вариант) ошиблись с индексом, скажем, в двухмерном массиве (а такая структура данных вполне обычна для расчетных задач, и не нужно никаких списков). И на стеке вы сможете задать лишь массивы фиксированной размерности, и если они вас не устроили - добро пожаловать в мир указателей со всеми его прелестями.
Которые не сложные (особенно если вы уже собаку съели на расшифровке определений типов в C), но на грабли которых все налево и направо наступают.
А найти более менее сложную программу (даже коммерческую), которая написана на C и при этом не страдает от утечек памяти хотя бы... Ну может это и возможно, но это не типично для таких программ.
По этому C нормально использовать там, где указатели именно требуются, а если есть возможность обойтись и без них - что угодно, только не C/С++.
До той же CUDA можно и на Java достучаться, к примеру. Но при этом прийдется вылавливать только ошибки, связанные с алгоритмом, и не тратить время на лозоходство по программе в поисках ошибок в работе с памятью.
no subject
>> вы сталкиваетесь с неожиданными данными в неожиданном месте всего лишь потому, что где-то (как вариант) ошиблись с индексом, скажем, в двухмерном массиве
В джава будет не так?
no subject
Если сравнить C# с Java как для перехода с Basic, так и для использования в последующем непрофессионалом, то:
- на C# выше порог вхождения. Его реально освоить сложнее
- в C# проще накосячить, из Java убрали практически все возможности делать ошибки, которые не относятся к самому алгоритму. В C# остались те же unsigned парные типы, которые могут смешиваться в выражениях со знаковыми типами и приводить к "неожиданным" (неожиданным для написавшего код) результатам.
- "один файл с именем класса - один публичный класс на файл" как требование языка делает код Java более переносимым. Если мне потребовалось использовать какие-то классы из одного проекта в других проектах, я просто создаю maven проект для библиотеки, перетаскиваю файлы классов (и только их) без изменений в проект библиотеки, добавляю в нужные проекты в pom зависимости от новой библиотеки.
При этом мне не пришлось менять ни буквы ни в одном файле с исходным кодом, так как Java изначально мне ограничила возможность устроить из своего когда помойку, которую невозможно повторно использовать.
- Java является реально кроссплатформенной, особенно при использовании JavaFX. Да и уйти с той же Windows на тот же Mac разработчику (ну купил макбук тот же человек себе) - вообще не проблема. Уходить можно даже вместе с любимой IDE. И не париться о том, что забыли какие-то библиотеки в случае использования maven. Т.е. вообще об этом не думать. То же самое в C#?
- у Java больше комьюнити, больше библиотек (а использование maven делает их подключение к проекту вообще тривиальным - вставка нескольких строк в pom файл, даже не нужно беспокоиться о том, где взять библиотеку и куда ее на компе приткнуть)
>В джава будет не так?
В Java с этим намного лучше не только, чем в C (где выход за границу массива не контролируется), но и в C# за счет отсутствия прямоугольных массивов (в Java есть только массивы массивов, и когда вам нужно создать треугольную матрицу вы создадите треугольную матрицу, и выйдя за границы тут же получите exception со стектрейсом).
Вообще, хороший критерий оценки языка программирования - это скорость падения программы в случае наличия в ней ошибок. Идеальным вариантом является падение на этапе компиляции (и хорошая IDE в фоне это может обнаружить при написания кода в редакторе). Ошибки, которые просочились сквозь компилятор, должны приводить к падению в рантайме максимально близко к месту их реального возникновения.
В случае C это совсем далеко не так (несмотря на его компилируемость), C# в целом не плох, но Java лучше
no subject
"Соскочить с Бейсика" не трудно. Трудность в том, что многие люди, овладевшие Бейсиком, языком алгоритмов при этом ухитрились не овладеть. Им придётся учиться другому языку программирования неделями. Автору этого ЖЖ - точно нет.
no subject
Я не преувеличиваю, а говорю о его наличии
>Никак не в синтаксисе конкретного языка программирования.
А при чем тут синтаксис? И "овладении языком алгоритмов в общем виде"?
Есть, к примеру, замечательный язык программирования Erlang (замечательный для решения некоторых задач, конечно). Синтаксис проще паренной репы. И что? Если вы не знакомы с функциональным программированием, то вам потребуется значительное время на освоение этого языка. И даже если вы знакомы с тем же Haskell, то перебраться на Erlang - это не раз плюнуть. Потому, что кроме изучения синтаксиса вам потребуется еще научиться этот синтаксис применять.
Если бы дело было бы только в синтаксисе, информацию из книг, посвященную тому или иному языку программирования, можно было бы засунуть в один номер пионерской правды.
>Автору этого ЖЖ - точно нет.
Вы делаете выводы не владея информацией, необходимой для того, чтобы эти выводы сделать.
no subject