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
>понять что у переменной адрес в памяти есть?
От того, что вы поймете, что есть адрес, вам легче нисколечко не станет.
Так как вам прийдется этими указателями управлять. Кроме просто понятия адреса есть стек и хип, к примеру. И если вы возвращаете из функции указатель на массив, созданной в ней на стеке, то вызывающий код будет неприятно удивлен тем, что он получит. При этом у него есть неплохой шанс удивиться не сразу, так как есть далеко ненулевая вероятность того, что в одном месте функция будет работать без последующего сваливания, а в другом вы будете получать полную лабуду. И будете гадать, в чем проблема - в коде, который функцию вызывает, или в самой функции.
>Тем более его никто не заставляет ими пользоваться.
Как и сам язык :)
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 лучше