Pascal (императивный, структурированный)
За: очень простой язык со строгим синтаксисом – прост для начинающих – на нем просто писать программы и отлаживать их.
Против: отсутствие стандартных библиотек (в сравнении с библиотеками C++ и Java).
C++ (поддерживает много парадигм(multi-paradigm) : объектно-ориентированное, обобщённое, процедурное, метапрограммирование)
За: STL (стандартная библиотека шаблонов) – много стандартных типов данных и алгоритмов. Большая “свобода” – можно реализовать одни и те же вещи по-разному. Хорошая производительность скомпилированного кода. Хорошая поддержка C++ сегодня.
Против: Отсутствие BigInteger и BigDecimal (они есть в библиотеках Java и C#). Возможны различные ошибки, вызванные непониманием между компилятором и программистом. Вы можете найти много тем об этом, но это не проблема языка. Но из-за очень большой свободы может быть сложнее писать и отлаживать программы на C++.
Java (объектно-ориентированный, структурный, императивный)
За: более строгий синтаксис, чем в C++ – более простое чтение кода – быстрая и простая отладка. Подсказки об ошибках и неиспользуемом коде. Очень много библиотек различного типа. Сборщик мусора. Новые возможности в последних версиях явы(пр.: вариации цикла for).
Против: Медленная работа программ (в 3-4 раза медленнее чем C/C++), длинный (постоянно длинный) код, но набор кода быстрый, потому что присутствует автодополнение.
Opinion of Petr: I think Java/C# (I don't see much difference between them except speed) are best suited for programming contests, since it's so much harder to make a mistake and so much easier to find and fix a mistake in a Java program than in a C/C++ program.
Much more strict type checking (implicit casts from long long to int and from int to bool??), out-of-range checking, code flow checking (allowing to read from uninitialized variables? why would a language allow that?), fantastic IDE which finds a lot of other mistakes for you, fantastically convenient debugging, more explicit syntax (a language with less power actually leads you to writing more readable programs), more explicit error messages (and the errors are always reproducible!) - to name a few advantages, but I've probably missed some more.
I think that writing correct programs and fixing them quickly when they're not correct far outweigh the disadvantages mentioned above (slower execution, longer programs). Even a 2x slowdown is almost never important in programming competitions, while a WA always is :) And I believe that most of the time at a programming contest is spent in thinking (including the thinking you do _while_ writing code), not in writing code, so the length of the program (or the typing speed, for that matter) is irrelevant.
And I believe the availability of various libraries is also not that important. So if I were to choose between C++ and Pascal, I'd choose Pascal because of the same argument (much more strict checking of everything).
Я не перевел мнение Петра, потому что оно намного лучше звучит на английском.
C# (поддерживает много парадигм(multi-paradigm) : объектно-ориентированное, обобщённое, процедурное программирование)
За: Быстрее чем Java. Стандартные библиотеки C#: в последней версии .NET присутствуют, как и в Java, классы для работы с длинной арифметикой, но теперь вы можете использовать их как переменные базовых типов: c=a+b, и т.п.
Против: Последняя версия .NET все еще не доступна на большинстве соревнований по программированию.
VB (процедурный, объектно-ориентированный, компонентно-ориентированный, событийно-ориентированный)
Отличие от C#: Язык программирования – Visual Basic, а не C#.
Мнение alliumnsk: VB.NET это всего лишь C# с синтаксисом Visual Basic, который был сделан, чтобы облегчить перенос программ, написанных на VB. Т.е. нет никаких причин думать о VB.NET.
Python (объектно-ориентированный, императивный, функциональный, аспектно-ориентированный)
Мнение _ph_:
За: Python - язык широкого назначения, на нем пишут практически любые типы программ, за исключением программ реального времени. Не случайно, питон - это официальный язык #3 в Google.
Python отлично подходит для решения не очень сложных задач благодаря краткости записи и наличию встроенных средств:
· встроенная длинная арифметика (как целочисленная, так и дробная)
· встроенные list (aka vector<>), set, dict, tuple (aka struct)
· библиотека для работы с регулярными выражениями re
· функция sorted() для любых последовательностей
· удобные строковые операции
· удобные конструкторы списков
· функции sum(), max(), min(), способные обрабатывать списки и т.д.
Против: К недостаткам Python с точки зрения олимпиадного программирования относятся:
· низкая скорость исполнения программ (в среднем проигрыш в 6 раз по сравнению с С++) и особенно медленный ввод-вывод (так что без специальных ухищрений 10^6 чисел даже прочитать за 1 сек. не успеешь)
· мало удобных IDE (единственная нормальная, что я знаю, PyDev для Eclipse)
PHP и другие языки программирования.
Пока я не вижу никаких причин использовать их на соревнованиях. Если у вас есть возражения - пишите.
Заключение:
Лучше всего знать и практиковать как можно больше языков, учиться, знать все нюансы, но это не так просто и не всегда возможно. Мы – люди, и мы не можем изменить своей природы, но мы можем постараться стать лучше. Каждый язык программирования имеет свои преимущества и недостатки, и вы всегда можете выбрать один из них для более эффективного решения определенных разных задач.
Вы должны решить для себя, чего вы хотите: гибкости и свободы языка или простоты написания, чтения, отладки и сопровождения программ; нужна ли вам высокая скорость, или ей можно пренебречь.
Надеюсь, что эта статья помогла вам понять отличия разных языков программирования, самые основные их преимущества и недостатки.
Дополнительная и использованная информация:
Ссылки:
Lisp as an Alternative to Java: http://norvig.com/java-lisp.html
Выбор оружия - обсуждение: http://codeforces.ru/blog/entry/254
Выбор оружия 2 – обсуждение: http://codeforces.com/blog/entry/316
C#. Почему не моно? : http://codeforces.ru/blog/entry/229
Немного о C# и Linq: http://codeforces.ru/blog/entry/245
Тесты и сравнение производительности Java, C#, C++:
· Умножаем матрицы (не читайте, если вы любитель Java)
Определения:
What does it mean?
С++ не функциональный язык программирования. Haskell или Lisp - да, а С++ - нет.
возможно, Вы подразумевали под словом "функциональный" немного другое - а именно слово "процедурный"?
я не спорю, что С++ поддерживает функциональную парадигму "некоторым образом". таким, о которым сами создатели С++ (наверно) и не подозревали. но, чтобы хоть как нибудь по-нормальному использовать данную парадигму, нужно еще написать кучу вспомогательного кода. спасибо, я лучше на хаскелле пофункциональничаю...
таким образом, я лично считаю, что теоретическая поддержка функциональной парадигмы не делает язык функциональным.
Linq - это работа с данными, то есть все, что крутится вокруг интерфейся IEnumerable<>
В 90% это все, что выглядит так:
(from v in bla where bla let bla orderby bla select bla)
Хотя это не более чем украшение (очень удобное) над методами IEnumerable.
BigInteger в C# - это просто тип данных, он не имеет отношения к Linq
На питоне ты не заморачиваешься со всякими низкоуровневыми операциями с данными, ты сразу пишешь алгоритм. В олимпиадном программировании имхо питон часто дает участнику громадное преимущество в скорости.
Минусы
- доступен не везде
- если важна скорость исполнения тривиальных операций ( типа считать большой объем данных, пробежаться по массиву и т.д. )
текущие версии питона показывают себя очень медленным языком.
Я не спорю с тем, что питон в том числе и функциональный, но это не первичная его парадигма. Я думаю в первую очередь он ОО язык.
А с каких пор С++ стал функциональным? Что именно в нем от функционального языка программирования?
expression templates,
boost::lambda
стандартно функциональная парадигма то не поддерживается, однако всегда можно извратиться и переделать язык под другую парадигму. даже тоже хаскелль можно заставить быть императивным :D
в Java я почти 0, поэтому ничего не могу сказать по поводу существования. но, думаю, аналог expression templates соорудить там можно. возможно, и не в виде шаблоном вообще, а как нибудь извратно и не так изящно, как на С++, но можно.
Unable to parse markup [type=CF_HTML]
прошу прощения, возможно вы меня не так поняли:) но все же я хочу донести свою мысль до Вас так, чтобы стало понятно.
еще раз. вы пишете интерпретатор с какого-то условного языка C@ на язык C++, используя прием "expression templates". чтобы Вы опять не назвали меня дураком из-за неточного применения термина, назовем это лучше не интерпретатором, а ПРОМТ-переводчиком из C@ в C++.
тут что происходит... вы пишете на C@, ПРОМТ-переводчик переводит это все в С++, а потом (как вы и сказали) оно компилируется в машинный код. но ведь у вас же нет изначально ПРОМТ-переводчика!
>даже тоже хаскелль можно заставить быть императивным
А без этого никуда. Если в языке ничего императивного нет, то даже вывести результат работы программы некуда :))
В обычной олимпиадной программе нет замедления в 3-4 раза только из-за того, что она переписана с C++ на Java.
Решения простых задач на Питоне, хотя и медленно работают, быстро и понятно пишутся. Встроенная длинная арифметика в Питоне тоже есть, причём не в виде BigInteger.add (a, BigInteger.valueOf (3)), а в виде a += 3. Также на Питоне влёт пишутся простые генераторы тестов.
>Сборщик мусора в Java — это на олимпиадах бывает не достоинство
А он вообще успевает запуститься за две-три секунды на тест? Хотя сборщик мусора замедляет работу, даже если и не запускается: из-за него компилятор не может класть значения куда угодно, а обязательно так, чтобы их потом GC мог найти.
>“в 3-4 раза медленнее, чем C++”.
А я вот только что проверил умножение матриц на 3 языках несколькими способами, и *самый быстрый* способ на Java оказался в ПОЛТОРА раза медленнее, чем *самый медленный* на Си++, и в ПЯТЬ раз медленее *самого быстрого* на Си++. *Самый простой* способ на Java -- и он же самый медленный в СЕМЬ с половиной раз медленее простейшего варианта на Си.
>Встроенная длинная арифметика в Питоне тоже есть, причём не в виде BigInteger.add
Да перегрузка операторов есть почти во всех языках высокого уровня. Даже варианты паскаля можно найти с перегрузкой операторов. Это только Java так отличилась отсутствием.
Можно исходники глянуть?
В 98% случаев (на нормальных олимпиадах) нет абсолютно никакой разницы и решения с одинаковой асимптотикой получают одинаковые вердикты.
На NEERC, например, практически все авторские решения пишутся на Java и ни у кого это почему-то вопросов не вызывает
Для C++ - GNU C++, для C# - MS.NET, для Java - Sun Java (JDK/JRE).
Нет, напротив, я все прочитал, может, не все дискуссии, но про автодополнение все и так понятно. Набирание кода программы и ее длина все-таки разные вещи, даже если набирать ее быстро.
Да, к сожалению, "потискать" C# я еще не успел(, поэтому о нем мог допустить ошибки в определениях, но суть та, что есть хорошие библиотеки и удобные "фичи".
Потом я еще подкорректирую и дополню текст.
Я сравнивал работу sort в C++ и, по-моему, Arrays.sort в java, а еще один из способов ввода информации, пока точно не могу его описать словами), с cin/cout в C++.
тот тест лежит здесь.
Программа явы отработала за 0.58 secs (49 total ticks), но, если я правильно понял, то ввод работал 93.9% от этого времени, на sort остается
А C++ (оптимизация -O2):
1) ср время ввода(ticks/1000): 150
ср время сортировки(ticks/1000): 42
2) с ios_base::sync_with_stdio(0);
ср время ввода(ticks/1000): 135
ср время сортировки(ticks/1000): 43
Этот тест я сделал навскидку, нормальный еще не перепровел, потому что хотел протестить еще и C#, но тогда сидел под линуксом - не было нормального C#, а сейчас на это времени пока нет + в яве очень много библиотек ввода-вывода, поэтому я не могу сказать, что то, что я написал вообще можно тестить или как-то воспринимать.
Про сборщик мусора: если он есть, то о мусоре уже можно не думать, хотя намного меньше контроля за оперативной памятью.
1. В олимпиадных задачах о сборке мусора можно не думать вообще - утечки памяти нам простят.
2. Программы на Си++ мусора не производят: я уже не помню, когда я в последний раз в олимпиадном коде на Си++ использовал ключевое слово new.
1. В олимпиадных задачах о сборке мусора можно не думать вообще - утечки памяти нам простят.
2. Программы на Си++ мусора не производят: я уже не помню, когда я в последний раз в олимпиадном коде на Си++ использовал ключевое слово new.
По поводу сравнения скорости кода, скомпилированного GCC и Visual Studio под виндой, могу сказать следующее. На олимпиадах и сборах обычно ставится Time Limit как двухкратное время работы самого быстрого из решений жюри (отдельно для Java, если это оправдано). На прошлых летних сборах в Петрозаводске у нас было аж три компилятора C++: MinGW g++ 3.4.2, экспериментальный MinGW g++ 4.4.0 и Visual C++, кажется, 2005. Ну и решения жюри на C++, по которым важно было поставить Time Limit, проверялись на всех трёх компиляторах. Так вот, быстрее с отрывом в несколько процентов бывали все три. Ну и случалась пару раз фигня, когда какой-то из компиляторов проигрывал раза в полтора. Почему — было сложно понять, это случалось на решениях жюри по 7-10 килобайт.
-- Ruby, в отличие от питона, можно назвать красивым. Хотя бы назвать.
-- Ruby несравненно тормознее. На Codeforces он успевает делать около 200к простых операций в секунду (слабо решить CBR4-D за квадрат на руби?).
Питон, за исключением ввода-вывода, невероятно быстр для скриптового языка. Невероятно.
Я ещё не пришёл к определённому мнению, но на контестах на Ruby, похоже, можно решать халяву, и, если наловчиться, даже быстрее, чем на других языках.
Из больших плюсов -- отличные регэкспы (см. мои сабмиты CBR5-A, если отсортировать по размеру, их видно)
Из больших минусов -- сложно дебажить
Вообще, рекомендую ознакомиться с Ruby всем тем, кто ещё не знаком.
Other languages include languages like Ruby and Perl, which have pretty much a similar set of advantages/disadvantages as Python, and dismissing them all as "no sense to use them in contests" sounds rather harsh and uninformed. Perhaps revising that line to something a little less dismissive, or omitting it altogether might be a good idea?
Apart from that, this is really a great article. +1 for the effort.