В этой статье мы реализуем одну и ту же программу с разными языками программирования, пытаясь понять, что их отличает. Это только после того, как мы немного поразмыслим, в чем вообще смысл всех этих языков? Мы посмотрим на C ++, Go, Rust, Swift, Python и Julia. Среди множества аспектов, которые мы могли бы оценить в этих языках, мы фокусируемся на приложениях для научного программирования и на том, что отличает Джулию от других. Неужели Джулия действительно говорит как Python и работает как C?

Вступление

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

Согласно Священным Писаниям, языки - это проклятие, наложенное на человечество Господом: «Давай, давай спустимся и запутаем людей разными языками. Тогда они не смогут понять друг друга ». –Бог. Небеса, 2354 год.

Науке тоже есть что сказать о языках. Индийский лингвист Канавили Раджагопалан пишет, что: Лингвистическая идентичность в значительной степени является политическим вопросом, а языки являются флагами верности. Это означает, что инструментальный взгляд на язык в корне ошибочен. Во всяком случае, это дотеоретическое ощущение того, что общение возможно или желательно (…), заставляет нас постулировать существование общего языка.

Сегодня программистов часто быстро и поверхностно обозначают в соответствии с основным языком, который они используют. Есть Java-программисты, Ruby-программисты, PHP-люди, Pythonistas и Haskellers. Объявления о вакансиях почти всегда требуют знания определенных языков программирования. В мультфильмах пытаются угадать, как должен выглядеть каждый из этих людей. Различия в языках часто подчеркиваются в нашей повседневной жизни, и только спорадические ссылки на общие концепции, такие как алгоритмы или шаблоны проектирования, позволяют нам преодолеть эти различия. Профессор Раджагопалан также говорит, Греческое чувство самоидентификации в значительной степени зависело от восприятия, что [варвары] были такими же людьми, как и сами греки, только разными. Как часто в наше время варвары тоже программисты?

Несмотря на то, что такая классификация кажется современной политикой идентичности, между пользователями разных языков программирования всегда был какой-то стресс. В книге Стивена Леви Хакеры очень подробно рассказывается о том, как некоторые ассемблерные программисты были недовольны популяризацией Basic. Даже создание первых компилируемых языков, таких как Фортран, столкнулось с сопротивлением людей, которые сочли это бессмысленным. Какая глупая трата времени, я прекрасно могу продолжать просто щелкать этими хлипкими переключателями бесконечно!

Я придумал эту последнюю цитату, поэтому позвольте мне привести настоящую ссылку на тот факт, что не все перешли на первые языки, как только они стали доступны: Fortrans 704 и 709 стали успешными довольно рано, особенно Fortran II, но проникновение по пользователям, так сказать, было довольно неравномерным. Наиболее опытные пользователи (…), как правило, сохраняли программирование на языке ассемблера, а самые новые и наименее изощренные новички в области вычислений чаще всего были пользователями Fortran.

Почему всегда есть люди, выступающие против новых технологий программирования? Возможно, дело не только в политике. Во-первых, не всегда ясно, что является законным технологическим прогрессом, а не просто шумихой, и некоторый здоровый скептицизм - это хорошо. Кроме того, программировать сложно, и большинство людей не могут позволить себе время и силы на изучение новых языков. Если вы можете выполнять свою работу с языком, работу, которая является сложной и которой вы гордитесь, это действительно может показаться глупым, оскорбительным или бесчувственным, если кто-то предложит вам или даже может сделать что-то по-другому. Это чувство гордости за свою работу, а также это чувство принадлежности к сообществу программистов определенного языка, разделяющих одни и те же ценности, похоже, связаны с идеей тумоса, которая очень хорошо обсуждается в недавняя книга Идентичность Фрэнсиса Фукуямы.

Однако мир не застыл во времени. Хотя многие древние языки, такие как C и LISP, обладают впечатляющей способностью оставаться живыми и актуальными, новые языки продолжают создаваться и приниматься программистами. Особенно начинающими программистами, которые часто могут без разбора выбирать между новым или устоявшимся языком в качестве первого. У любого программиста, начинающего или нет, созерцающего современную панораму языков, естественно возникают следующие вопросы: в чем же разница между ними? А какой язык мне учить?

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

Расцвет научного Python

В конкретном контексте научного и числового программирования, анализа данных и машинного обучения этот вопрос сейчас особенно сложен, потому что много чего происходит. Это область, в которой, прежде всего, всегда было ощущение, что для достижения максимальной скорости вам в конечном итоге придется перенести свой код на «старый добрый» C ++ или Fortran. Однако до того, как это произошло, вы должны были создавать прототипы и экспериментировать с более интерактивными и динамическими языками, такими как Matlab, R и Mathematica, или, может быть, с языками 90-х, такими как Perl, Python, Ruby, Lua и Tcl, не говоря уже о случайных сценариях Bash и SQL-запрос. А некоторые задачи по своей сути экспериментальные и интерактивные. Java также использовалась в этой области в последние десятилетия, хотя, вероятно, больше мотивировалась ее предыдущим внедрением в компаниях по другим причинам. И помимо языков и библиотек, конечно, есть такие инструменты, как Weka.

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

1. Простота взаимодействия с эффективными скомпилированными библиотеками.

2. Краткий, «чистый» синтаксис, являющийся результатом таких функций, как динамическая отправка и сборка мусора, не говоря уже о более сложном синтаксическом анализаторе, на который у большинства людей хватило терпения написать до 1980-х годов.

3. Сообщество. Веселый и гостеприимный с 1990-х годов Python сумел привлечь и удержать людей с разными интересами, от системных администраторов, веб-разработчиков и разработчиков игр до более ученых, таких как создатели таких пакетов, как numpy, scipy, scikit и matplotlib.

Однако не очевидно, почему именно Python приобрел такую ​​популярность. Другие динамические языки предлагали что-то похожее на Python, а некоторые были приняты в науке о данных и глубоком обучении. Например, Perl предлагает массивы, подобные Numpy, через библиотеку PDL, а также имеет статистические пакеты на CPAN. У него также было большое сообщество и множество «включенных батарей». У Octave было довольно солидное предложение в качестве бесплатного клона Matlab. Что касается глубокого обучения, мы можем сослаться на фреймворк Torch, основанный на Lua, который определенно имел некоторую популярность. В то время Ruby казался ничем не хуже Python, и в конце концов он стал популярным только в веб-разработке, а не в числовой работе.

Книга Маккристала и др. Лидеры: миф и реальность повествует о жизни ряда выдающихся личностей и поднимает вопрос о том, как эти люди стали великими лидерами. В итоге приходит к выводу, что лидерство не так сильно зависит от личностных качеств или всего, что этот лидер может делать. Хотя они всегда усердно работают, успешное лидерство, похоже, больше зависит от символики, а не от реальных поставленных товаров, от среды, в которой находился лидер, от окружающих его организаций, и, прежде всего, хорошее лидерство зависит от воли его последователей. приветствовать и следовать за этим лидером. Также решающим фактором может быть удача.

Что это могло значить для языков? Хотя отличные языки, такие как Python или JavaScript, действительно предлагают своим пользователям некоторые удивительные функции, широкое распространение может зависеть от большего, чем это, или даже от знаменитых батарей. Это может зависеть от того, как институты поддерживают разные языки, что этот язык может со временем символизировать для разных людей, и в основном зависит от решения отдельных людей продолжать изучать язык. Под этим я подразумеваю наличие спроса, некоторую жажду разработчиков поцарапать и готовность искать ответ на другом языке. И, наконец, удача может быть частью всего.

Заметьте, я не упомянул здесь популярность. Это может быть частью того, что движет некоторыми разработчиками в некоторых ситуациях. В другой ситуации все может быть с точностью до наоборот, некоторые люди могут искать именно уникальный язык. Хотя, безусловно, доступ к информации и опытным коллегам может быть фактором, побуждающим разработчика выбрать язык, ни один язык не может быть популярным с самого начала, и я думаю, что мы считаем популярность важным фактором в принятии языка гораздо чаще, чем это есть на самом деле. имеет значение. Это просто упрощенный и наивный взгляд на то, что побуждает людей следовать за лидером или выбирать язык программирования для изучения. Мы не просто «овцы»!

Растущие потребности в динамических языках

Python определенно сделал огромный путь от языка сценариев для систем, чтобы стать крупным игроком в области численного программирования среди Matlab и C ++. Хотя успех очевиден, у языка определенно есть свои ограничения, которые понимают его пользователи. Хорошее собеседование, посвященное Python, затронет эти темы, и некоторые из наиболее важных инструментов и методов, используемых в Python, связаны с этими ограничениями. И некоторые из этих ограничений имеют глубокие корни.

Первое - это производительность. Вы просто не можете ожидать высокой производительности от чистого кода Python при выполнении задач численного программирования. Python может отставать даже по сравнению с другими интерпретируемыми динамическими языками, такими как JavaScript. Однако этот язык никогда не задумывался как эффективный. Немного преувеличивая, просить об этом - все равно что требовать высокой производительности, например, от интерпретатора bash.

Впечатляет то, как Python пытался преодолеть свои ограничения производительности. Хотя были промахи, такие как Unladen Swallow, были и такие хиты, как IronPython и PyPy. И вдобавок ко всему, конечно, широко успешная реализация парадигмы Matlab-ish выполнения быстрых векторных операций над массивами, реализованная Numpy. Это привело к большему количеству побед с использованием Python поверх низкоуровневых библиотек, таких как OpenCV и TensorFlow. Помимо успеха Python как «связующего языка», такие проекты, как Cython an Numba, демонстрируют, что платформа может пойти еще дальше.

Другое важное ограничение Python связано с его системой типов невмешательства. Python обычно следует подходу «утиной печати», что в основном означает, что каждая функция является полностью универсальной, и пока существуют базовые функции, которые могут принимать типы операторов, найденные во время выполнения, они будут просто запускаться. Такая гибкость имеет неоспоримые преимущества для опыта разработки и является одной из основных причин популярности динамических языков. Однако у этого есть и другая сторона, и опытные разработчики знают, что со временем это может создать проблемы. Например, может быть трудно понять, как использовать слишком абстрактный фрагмент кода. «Каковы даже ожидаемые типы переменных?»

Часто бывает полезно проверить тип входного аргумента, чтобы убедиться, что нет никаких скрытых ошибок, потому что функция не используется по назначению. Обсуждениям об обязательном объявлении типов в языках программирования не менее 1963 года, как показывает эта цитата Хора из комитета по Алголу. Это убедительная история, но на самом деле неудача Mariner I была вызвана опечаткой в ​​имени переменной, хотя можно утверждать, что эту ошибку также можно было предотвратить с помощью проверки типов.

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

Учитывая эволюцию Python и других динамических языков в последние десятилетия, кажется, что сначала было массовое внедрение, за которым последовала тяга к производительности и системе типов. Помимо Python, это также можно наблюдать в JavaScript, где V8 сначала принес большие улучшения производительности, а совсем недавно TypeScript внес другой вклад. Другой язык, который недавно представил систему необязательных типов, - это Racket, который также был нацелен на дальнейшее улучшение своей производительности за счет принятия Chez Scheme в качестве своего рода серверной части компилятора.

События на статическом фронте

Не ограничиваясь динамическими языками, мы можем увидеть ряд скомпилированных и проверенных типом языков, которые были предложены в последнее десятилетие и набирают популярность. В качестве примеров можно привести Swift, Rust и Go. Все они пользуются поддержкой крупных организаций и множества умных людей, работающих над ними. Тот факт, что они скомпилированы, означает, что они могут предложить желаемую производительность для числовых приложений, а тот факт, что они в некотором роде «современные», означает, что они могут предложить по крайней мере некоторые улучшения удобства использования по сравнению с такими языками, как C ++ и Fortran. Может ли научное сообщество поддерживать эти языки так же, как Python или Matlab?

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

Rust в основном приносит те же улучшения по сравнению с C и C ++, что и Java в 90-х годах. Это необходимое aggiornamento для низкоуровневых системных языков означает предложение таких функций, как автоматическая проверка границ для доступа к массиву, автоматическое управление памятью посредством подсчета ссылок или других форм сборки мусора, улучшенная поддержка неизменяемости и менее автоматические преобразования типов, такие как целое число в логическое. - Важно отметить, что именно этот последний факт многие люди подразумевают под «языком с сильной / слабой типизацией», что отличается от наличия явных типов аргументов в объявлениях функций. Это также отличается от динамической / статической типизации.

Некоторые сегодня считают C и C ++ прекрасными языками, способными предложить все вышеперечисленное. Просто у них неправильные значения по умолчанию или они требуют осторожности. Это звучит как хороший аргумент, хотя он не сильно отличается от пункта выше, что большинство языков могут делать все. Эти «значения по умолчанию» на самом деле являются решающими в вашем опыте программирования на этом языке. Если вы изо всех сил пытаетесь заставить что-то происходить так, как вы хотите, язык на самом деле не помогает, и вам может быть лучше создать целый язык, который выводит код C, например Cython или Nim. Хотя может показаться, что может помочь решить проблемы в C и C ++, чтобы поговорить о неправильных настройках по умолчанию и предупредить о необходимой работе и осторожности, это именно то, что побуждает разработчиков выбирать Python вместо C, Fortran вместо Assembly и т. Д. .

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

Go сильно отличается от Rust, потому что, помимо попытки предложить правильные значения по умолчанию, он предлагает своего рода аскетизм, которого, кажется, жаждут некоторые программисты. Это проявляется в отсутствии параметрического полиморфизма. Однако аскетизм не является явным желанием. Создатели Go заявляют о своей цели в основном сократить время компиляции и обеспечить общую простоту. Сознательно или нет, но дизайн Go, похоже, каким-то образом использует парадокс выбора. Что бы они ни пытались сделать, похоже, что проект в этом преуспел. Стоимость этих ограничений, похоже, сильно меняется у разных программистов, а это означает, что есть люди, которые просто не смогут использовать язык, в то время как, похоже, есть большая публика, которая им довольна. Даже очень доволен. Сомнительно, может ли это понравиться некоторым нишам, в том числе научным программистам.

В то время как Rust начинал при поддержке Mozilla Foundation и Go от Google, Swift был создан Apple, чтобы стать официальным языком для разработки под iOS, заменив Objective-C, название которого указывает на какое-то вдохновение. Swift, похоже, сохранил некоторый багаж от своего предшественника, чего и следовало ожидать. Тем не менее, он предлагает что-то новое, возможно, главное, что его компилятор основан на LLVM, как и Rust, но в отличие от Go.

Swift не считался деструктивным языком в процитированном нами веб-семинаре, возможно, потому, что сначала он стремился заменить Objective-C, обслуживая ту же аудиторию. Однако в последнее время некоторые люди предлагают Swift как язык, который может что-то предложить научным программистам. Центральным элементом этой идеи является проект Swift для TensorFlow.

График выглядит примерно так: в начале 2000-х Крис Латтнер создал LLVM в UIUC, с помощью которого был разработан Clang, а позже и многие другие проекты. Позднее Латтнер был нанят в Apple, где он создал Swift на основе LLVM (и кое-что из этого багажа Objective-C). Сейчас он работает в Google и развивает свои успехи в проекте Swift for TensorFlow.

Одним из основных разработчиков Swift для TensorFlow был Ричард Вей, который пошел по стопам Латтнера, работая в той же группе UIUC, Apple, а затем Google. Похоже, что семенем Swift для TensorFlow является его дипломный проект, который обсуждался в этой презентации на встрече разработчиков LLVM в 2017 году. Помимо поддержки со стороны Google, проект также получил некоторую внешнюю оценку, в частности, Fast.ai из Кремниевой долины.

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

Этот блог здесь - прекрасная иллюстрация трудностей, с которыми может столкнуться любой, кто пытается интегрировать TensorFlow с Go или Rust, а также того, насколько сложен был сам Swift. У Swift, кстати, тоже была своя ухабистая поездка: от чего-то, что строго используется для приложений iOS, превратилось во что-то, что можно было бы использовать на сервере или для научного программирования.

Последний удар в Swift - это, возможно, в прошлом месяце Ричард Вей, объявивший, что он покидает проект. Хотя проект по-прежнему пользуется сильной институциональной поддержкой, на некоторые важные вопросы о том, можно ли все это действительно интегрировать в Swift, так и не ответили. Остается неясным, каков потенциал S4TF как практического инструмента, а не просто как хорошо работающего прототипа, демонстрирующего многие из того, что ищут современные научные программисты.

Создание инструмента для работы

Начиная с S4TF, Python и даже C, мы неоднократно говорили здесь о языках, которые используются для научного программирования в последнюю очередь. Это контрастирует с языками, созданными с этой целью с самого начала, такими как Mathematica, R, Matlab, Fortran или APL. Это не означает, что первые языки не могут быть хорошими, и это не означает, что вторые языки лучше по своей сути: они действительно сталкиваются с проблемами при переходе от прототипирования к коммерческим приложениям, например.

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

Это язык Юля. Все началось в Массачусетском технологическом институте, который обеспечивает институциональную поддержку. Он находится в разработке уже много лет, и версия 1.0, выпущенная в прошлом году, стала важной вехой. Зрелость, достигаемая основным языком, дополняется некоторыми замечательными инструментами, такими как система пакетов и отладчик, не говоря уже о многих пакетах, которые помогают разработчикам работать с дифференциальными уравнениями и обработкой изображений вплоть до написания. HTTP-сервер или скрипты для запуска внешних процессов.

В то время как динамические функции Джулии в сочетании с ее тесной интеграцией с LLVM позволяют Джулии решать так называемую проблему двух языков, Джулия также предлагает отличную интеграцию с другими языками, включая Python и C. У нее есть сообщество с сильным академическим образованием, с некоторые довольно активные интернет-ресурсы, такие как форум и рабочая среда Slack. У него также есть отличная конференция, и многие ее доклады доступны на YouTube.

Эксперименты

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

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

Это различие между этими группами языков может создать впечатление, что между ними существует некий естественный компромисс. Как будто язык может быть либо быстрым и надежным в использовании, либо удобным и приятным для написания. Как только «динамический» язык предлагает статический анализ, как с MyPy, или форму компиляции времени выполнения, такую ​​как граф TensorFlow, или когда C ++ начинает предлагать встроенную динамическую отправку и систему шаблонов, которая эффективно позволяет вам выполнять «утиную типизацию» ”, Имеет ли смысл номенклатура?

В действительности нет никакого парадокса. Мы считаем, что существует естественная эволюция языков программирования, а конкретные ограничения, которые мы видим, случайны.

Гипотеза нашего эксперимента состоит в том, что Джулия позволяет писать код, очень похожий на Python, высокий стандарт качества синтаксиса, а также обеспечивает производительность C ++, высокий стандарт эффективности кода. Непросто дать хорошую объективную оценку этим вещам, хотя мы считаем, что попробовать это лучше, чем просто размахивать руками и оставлять вас без каких-либо практических аргументов в поддержку всех многих слов, уже высказанных в этой статье!

Покажи мне код

Мы реализовали проблему внесения изменений на нескольких языках, и код доступен по адресу: https://gist.github.com/nlw0/04ec031eaa839d5e358d7ad0d194c497

Мы предлагаем эти числа в качестве оценки производительности, решая задачу для числа 907 с номиналами монет {11,10,1}.

C++: 3.775 ms

Юля: 3,315 мс

Python: 15,098 мс

Можно с уверенностью сказать, что Джулия может достичь той же производительности, что и C ++. В данном случае здесь она даже немного превзошла разницу, которая, скорее всего, связана с небольшим изменением реализации, которое может найти прилежный программист. С другой стороны, Python как минимум в 4 раза медленнее, чем Julia или C ++. На самом деле неплохая производительность, в других случаях Python может быть намного медленнее.

Что касается схожести синтаксиса, мы провели тест с использованием diff. Скрипт можно найти по сути выше, и все результаты попарного сходства также можно найти по сути. Вот сходство только относительно Python:

Python: 1.0
Julia: 0,61
JavaScript: 0,55
Swift: 0,46
Go: 0,33
Rust: 0,30
C ++: 0,30

Тот факт, что JavaScript получил высокие оценки, а C ++ - низкий, должен подтверждать это измерение языкового сходства. Примечательно, что в этом тесте на «питоничность» Джулия получила самый высокий балл по сравнению со всеми другими языками.

Заключение

Значение языков программирования в нашей жизни только возросло с момента их создания, и они показали, что они очень устойчивые сущности. Хотя в компьютерных технологиях произошли большие преобразования, от процессоров до сетей, некоторые языки программирования, кажется, могут жить вечно после достижения определенного уровня популярности. Языки играют в нашей жизни роль, выходящую за рамки их строго технического предназначения. Они образуют сплоченную точку для формирования сообществ программистов, а изучение конкретных языков программирования часто объединяется с изучением других общих тем, включая информатику.

В первые десятилетия существования языков программирования были исследованы различные парадигмы, и многие инициативы показали нам, что с ними можно делать. Современные языки программирования создаются в другом контексте, и улучшения в разработке программного обеспечения в целом позволяют языкам программирования каждый день предлагать новые функции, которые в прошлом, как правило, оставались эксклюзивными для языков, на которых они были впервые созданы. Среди этих технологических усовершенствований мы можем особо выделить LLVM как один из важных инструментов, который позволил использовать многие из самых интересных языков, созданных за последнее десятилетие или около того. JVM также имела аналогичный эффект, не говоря уже о GCC.

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

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

Эта статья началась с намерением защитить язык Julia. Однако многие программисты Джулии - ученые и академики, и, следуя этой природе, этот текст стал научным. И все же оказывается, что защита языка может быть чем-то строго риторическим.

Если мы попытаемся найти очень веские объективные причины для использования Julia, мы, вероятно, всегда будем проводить эксперименты, аналогичные тем, которые мы показали ранее. Мы можем показать хорошее время работы, и если есть такая вещь, как хороший тест на «чистый синтаксис», кажется, язык выдержит это. Он также определенно может удовлетворить современные потребности, такие как работа на графических процессорах и автоматическая дифференциация. Он ставит много отметок.

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

Наш окончательный вывод должен заключаться в том, что вам, вероятно, нужно слышать, чтобы не ученый объяснял вам, почему следует выбрать язык, а вместо этого поэт. Бразильская писательница Кларис Лиспектор однажды написала:

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

Попробуй Юлю сегодня!