Что привлекает людей в динамических языках?
Кажется, что в последнее время все прыгают на динамичной, не скомпилированной победе. В основном я работал только на скомпилированных языках со статической типизацией (C, Java, .Net). У меня есть опыт работы с динамическими языками, например ASP (Vb Script), JavaScript и PHP. Использование этих технологий оставило у меня неприятный вкус, когда я думал о динамических языках. Вещи, которые обычно были бы обнаружены компилятором, такие как имена переменных с ошибками и присвоение значения неправильного типа переменной, не происходят до времени выполнения. И даже в этом случае вы можете не заметить ошибку, поскольку она просто создает новую переменную и присваивает некоторое значение по умолчанию. Я также никогда не видел, чтобы intellisense хорошо работал на динамическом языке, поскольку переменные не имеют явного типа.
Что я хочу знать, так это то, что люди находят настолько привлекательным в динамических языках? Каковы основные преимущества с точки зрения того, что динамические языки позволяют вам делать, чего нельзя сделать или трудно сделать в скомпилированных языках. Мне кажется, что мы давно решили, что такие вещи, как некомпилированные asp-страницы, генерирующие исключения во время выполнения, были плохой идеей. Почему происходит возрождение этого типа кода? И почему, по крайней мере, мне кажется, что Ruby on Rails на самом деле не похож на то, что вы не могли сделать с ASP 10 лет назад?
32 ответа
Я думаю, что причина в том, что люди привыкли к статически типизированным языкам, которые имеют очень ограниченные и невыразительные системы типов. Это такие языки, как Java, C++, Pascal и т. Д. Вместо того, чтобы идти в сторону более выразительных систем типов и лучшего вывода типов (как, например, в Haskell и даже в некоторой степени SQL), некоторым людям нравится просто сохранять вся информация о "типах" в их голове (и в их тестах) и вообще избавляет от статической проверки типов.
Что это купит вас в конце концов, неясно. Есть много неправильных представлений о проверке типов, из которых я чаще всего сталкиваюсь, это два.
Ошибка: Динамические языки менее многословны. Заблуждение состоит в том, что информация о типе равна аннотации типа. Это совершенно не соответствует действительности. Мы все знаем, что аннотация типа раздражает. Машина должна быть в состоянии разобраться с этим. И на самом деле это происходит в современных компиляторах. Вот статически типизированная QuickSort в двух строках Haskell (из http://haskell.org/):
qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)
А вот динамически типизированная QuickSort в LISP (от swisspig.net):
(defun quicksort (lis) (if (null lis) nil
(let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
(append (quicksort (remove-if-not fn r)) (list x)
(quicksort (remove-if fn r))))))
Пример на Haskell фальсифицирует гипотезу, типизированную статически, поэтому многословно. Пример LISP подделывает гипотезу многословно, поэтому статически типизирована. Между печатанием текста и многословием нет никакого смысла. Вы можете смело выбросить это из головы.
Ошибка: статически типизированные языки должны быть скомпилированы, а не интерпретированы. Опять не правда. Многие статически типизированные языки имеют переводчиков. Есть интерпретатор Scala, интерпретаторы GHCi и Hugs для Haskell, и, конечно, SQL статически типизирован и интерпретируется дольше, чем я был жив.
Знаете, может быть, динамичная толпа просто хочет свободы, чтобы не думать так тщательно о том, что они делают. Программное обеспечение может быть неправильным или надежным, но, возможно, это не обязательно.
Лично я думаю, что те, кто отказался бы от безопасности типов, чтобы приобрести немного временной свободы, не заслуживают ни свободы, ни безопасности типов.
Не забывайте, что вам нужно написать 10-кратное покрытие кода в модульных тестах, чтобы заменить то, что делает ваш компилятор:D
Я был там, сделал это с динамическими языками, и я не вижу абсолютно никаких преимуществ.
При чтении ответов других людей кажется, что есть более или менее три аргумента для динамических языков:
1) Код менее многословен. Я не нахожу это действительным. Некоторые динамические языки менее многословны, чем некоторые статические. Но F# имеет статическую типизацию, но статическая типизация там не добавляет много кода, если он вообще есть. Это неявно напечатано, хотя, но это совсем другое.
2) "Мой любимый динамический язык X имеет мою любимую функциональную особенность Y, поэтому динамический лучше". Не путайте функциональность и динамику (я не могу понять, почему это должно быть сказано).
3) В динамических языках вы можете увидеть свои результаты сразу. Новости: Вы можете сделать это с помощью C# в Visual Studio (с 2005 года). Просто установите точку останова, запустите программу в отладчике и измените программу во время отладки. Я делаю это все время, и это работает отлично.
Я являюсь активным сторонником статической типизации по одной основной причине: удобство обслуживания. У меня есть система с парой 10 000 строк JavaScript, и любой рефакторинг, который я хочу сделать, займет полдня, так как (несуществующий) компилятор не скажет мне, что испортила переименование переменной. И этот код я написал сам, ИМО тоже хорошо структурирован. Я бы не хотел, чтобы задача отвечала за эквивалентную динамическую систему, написанную кем-то другим.
Я полагаю, что за это я получу огромное количество голосов, но я рискну.
VBScript - отстой, если вы не сравниваете его с другой разновидностью VB. PHP в порядке, если вы помните, что это заросший шаблонный язык. Современный Javascript великолепен. В самом деле. Тонны веселья. Просто держитесь подальше от любых сценариев с тегом "DHTML".
Я никогда не использовал язык, который не допускал ошибок во время выполнения. ИМХО, это в основном красная сельдь: компиляторы не улавливают все опечатки и не проверяют намерения. Явная типизация хороша, когда вам нужны явные типы, но в большинстве случаев это не так. Поиск вопросов здесь generics или вопрос о том, было ли использование типов без знака хорошим выбором для индексных переменных - большую часть времени этот материал просто мешает и дает ручкам людей вертеться, когда у них есть время.
Но я не ответил на ваш вопрос. Почему динамические языки привлекательны? Потому что через некоторое время написание кода становится скучным, и вы просто хотите реализовать алгоритм. Вы уже сидели и работали над пером, наметили сценарии потенциальных проблем и доказали, что они решаемы, и единственное, что остается сделать, - это написать код для двадцати строк реализации... и двухсот строк шаблона для компиляции, Затем вы понимаете, что система типов, с которой вы работаете, отражает не то, что вы на самом деле делаете, а чье-то ультра-абстрактное представление о том, что вы можете делать, и вы давно отказались от программирования ради жизни с безделушкой, так навязчиво-навязчиво, что это будет позором даже вымышленного детектива Адриана Монка.
Вот когда вы начнете оштукатуряться и начнете серьезно смотреть на динамические языки.
Я штатный программист.Net, полностью укоренившийся в муках статически типизированного C#. Тем не менее, я люблю современный JavaScript.
Вообще говоря, я думаю, что динамические языки позволяют вам выражать свои намерения более лаконично, чем языки со статической типизацией, поскольку вы тратите меньше времени и места на определение того, что представляют собой строительные блоки для того, что вы пытаетесь выразить, когда во многих случаях они самоочевидны.
Я думаю, что есть также несколько классов динамических языков. У меня нет желания возвращаться к написанию классических ASP-страниц на VBScript. Чтобы быть полезным, я думаю, что динамический язык должен поддерживать своего рода коллекцию, список или ассоциативную конструкцию в своей основе, чтобы объекты (или то, что передается для объектов) могли быть выражены и позволяли вам строить более сложные конструкции. (Может быть, мы все должны просто написать код на LISP ... это шутка...)
Я думаю, что в кругах.Net динамические языки получают плохую репутацию, потому что они связаны с VBScript и / или JavaScript. VBScript - это просто кошмар, вызванный многими причинами, о которых говорил Кибби, - кто-нибудь помнит принудительное использование типа в VBScript с помощью CLng, чтобы убедиться, что у вас достаточно битов для 32-разрядного целого числа. Кроме того, я думаю, что JavaScript все еще рассматривается как язык браузера для выпадающих меню, который написан по-разному для всех браузеров. В этом случае проблема заключается не в языке, а в различных объектных моделях браузера. Интересно, что чем больше созревает C#, тем динамичнее он начинает выглядеть. Я люблю лямбда-выражения, анонимные объекты и вывод типов. Это больше похоже на JavaScript каждый день.
Вот статически типизированная QuickSort в двух строках Haskell (из haskell.org):
qsort [] = [] qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)А вот динамически типизированная QuickSort в LISP (от swisspig.net):
(defun quicksort (lis) (if (null lis) nil (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x)))) (append (quicksort (remove-if-not fn r)) (list x) (quicksort (remove-if fn r))))))
Я думаю, что вы склоняете вещи с вашим выбором языка здесь. Лисп очень печально известен. Более близким к Хаскелу будет Python.
if len(L) <= 1: return L
return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])
Код Python отсюда
Для меня преимущество динамических языков заключается в том, насколько более читабельным становится код из-за меньшего количества кода и функциональных методов, таких как блок Ruby и понимание списка Python.
Но потом я как бы пропускаю проверку времени компиляции (опечатка случается) и автозаполнение IDE. В целом, меньшее количество кода и читабельность окупаются для меня.
Другим преимуществом является обычно интерпретируемая / не скомпилированная природа языка. Измените некоторый код и сразу увидите результат. Это действительно экономит время в процессе разработки.
И последнее, но не менее важное: мне нравится тот факт, что вы можете запустить консоль и попробовать что-то, в чем вы не уверены, например, класс или метод, который вы никогда раньше не использовали, и посмотреть, как он себя ведет. Существует много вариантов использования консоли, и я просто оставлю это для вас, чтобы разобраться.
Ваши аргументы против динамических языков совершенно верны. Однако учтите следующее:
- Динамические языки не нужно компилировать: просто запустите их. Вы даже можете перезагрузить файлы во время выполнения без перезапуска приложения в большинстве случаев.
- Динамические языки, как правило, менее многословны и более читабельны: вы когда-нибудь рассматривали данный алгоритм или программу, реализованную на статическом языке, а затем сравнивали его с эквивалентами Ruby или Python? В общем, вы смотрите на сокращение количества строк кода в 3 раза. Многие динамические коды не нужны в динамических языках, и это означает, что конечный результат более читабелен и более сфокусирован на конкретной проблеме.
- Не беспокойтесь о проблемах с типизацией: общий подход при программировании на динамических языках - не беспокоиться о типизации: в большинстве случаев правильные аргументы будут передаваться вашим методам. И время от времени, кто-то может использовать другой тип аргумента, который, как оказалось, тоже работает. Когда что-то идет не так, ваша программа может быть остановлена, но это случается редко, если вы провели несколько тестов.
Поначалу мне тоже было немного страшно отойти от безопасного мира статической типизации, но для меня преимущества намного перевешивают недостатки, и я никогда не оглядывался назад.
Я считаю, что "новая найденная любовь" к языкам с динамической типизацией связана не столько с тем, являются ли языки со статической типизацией лучше или хуже - в абсолютном смысле, - чем с ростом популярности определенных динамических языков. Очевидно, что Ruby on Rails - большое явление, которое вызывает возрождение динамических языков. То, что сделало рельсы настолько популярными и создало так много новообращенных из статического лагеря, было главным образом: очень краткий и СУХОЙ код и конфигурация. Это особенно верно по сравнению с веб-фреймворками Java, которые требуют горы конфигурации XML. Многие Java-программисты - тоже умные - конвертировали, а некоторые даже проповедовали рубин и другие динамические языки. Для меня три отличных особенности позволяют динамическим языкам, таким как Ruby или Python, быть более краткими:
- Минималистский синтаксис - главный из них заключается в том, что аннотации типов не требуются, но также разработчик языка с самого начала разработал язык для краткости
- Синтаксис встроенных функций (или лямбда) - способность писать встроенные функции и передавать их как переменные делает многие виды кода более краткими. В частности, это верно для операций со списком / массивом. Корни этой идеи были, очевидно, - LISP.
- Метапрограммирование - метапрограммирование - большая часть того, что заставляет рельсы тикать. Это дало начало новому способу рефакторинга кода, который позволил клиентскому коду вашей библиотеки быть намного более кратким. Это также происходит от LISP.
Все эти три функции не являются эксклюзивными для динамических языков, но они, безусловно, отсутствуют в популярных современных статических языках: Java и C#. Вы можете утверждать, что в C# есть #2 в делегатах, но я бы сказал, что он вообще не используется широко - например, в операциях со списками.
Что касается более продвинутых статических языков... Haskell - замечательный язык, у него есть #1 и #2, и хотя у него нет #3, его система типов настолько гибка, что вы, вероятно, не найдете недостатка в быть ограничивающим. Я считаю, что вы можете выполнять метапрограммирование в OCaml во время компиляции с расширением языка. Scala является очень недавним дополнением и очень перспективным. F# для.NET лагеря. Но пользователи этих языков находятся в меньшинстве, и поэтому они действительно не внесли свой вклад в это изменение ландшафта языков программирования. На самом деле, я очень верю, что популярность Ruby положительно повлияла на популярность таких языков, как Haskell, OCaml, Scala и F#, в дополнение к другим динамическим языкам.
Лично я считаю, что большинство "динамических" языков, которые вы использовали, оказались плохими примерами языков в целом.
Я гораздо более продуктивен в Python, чем в C или Java, и не только потому, что вы должны танцевать edit-compile-link-run. Я стал более продуктивным в Objective-C, но это, вероятно, больше из-за структуры.
Излишне говорить, что я более продуктивен в любом из этих языков, чем в PHP. Черт, я бы лучше написал код на Scheme или Prolog, чем на PHP. (Но в последнее время я на самом деле делал больше Пролога, чем что-либо еще, так что возьмите это с собой!)
Ах, я не видел эту тему, когда я отправил аналогичный вопрос
Помимо хороших возможностей, упомянутых здесь о динамических языках, я думаю, что все забывают одну, самую основную вещь: метапрограммирование.
Программирование программы.
Это довольно сложно сделать на скомпилированных языках, как, например,.Net. Чтобы заставить его работать, вы должны сделать все виды мамбо-джамбо, и это обычно заканчивается кодом, который работает примерно в 100 раз медленнее.
У большинства динамических языков есть способ выполнять метапрограммирование, и это то, что меня удерживает - возможность создавать любой вид кода в памяти и идеально интегрировать его в мое приложение.
Например, чтобы создать калькулятор в Lua, все, что мне нужно сделать, это:
print( loadstring( "return " .. io.read() )() )
Теперь попробуйте сделать это в.Net.
Одно из преимуществ динамических языков - возможность изменить код и продолжить работу. Не нужно перекомпилировать. В VS.Net 2008 при отладке вы можете изменить код и продолжить работу без перекомпиляции. С достижениями в компиляторах и IDE, возможно, что это и другие преимущества использования динамических языков исчезнут.
Моя оценка динамических языков очень сильно зависит от их функциональности. Понимание списка Python, замыкания Ruby и прототипированные объекты JavaScript - все это очень привлекательные аспекты этих языков. Все также имеют первоклассные функции - то, без чего я больше не смогу жить.
Я бы не классифицировал PHP и VB (скрипт) одинаково. Для меня это в основном императивные языки со всеми недостатками динамической типизации, которые вы предлагаете.
Конечно, вы не получаете тот же уровень проверок во время компиляции (поскольку нет времени компиляции), но я ожидаю, что инструменты статической проверки синтаксиса со временем будут развиваться, чтобы хотя бы частично решить эту проблему.
Моя главная причина, по которой мне нравятся динамические (типизированные, так как кажется, что это основное внимание в потоке) языки, состоит в том, что те, которые я использовал (в рабочей среде), намного превосходят те, которые я использовал не в динамических языках. C, C++, Java и т. Д. - все они ужасные языки для выполнения реальной работы. Мне бы хотелось увидеть неявно типизированный язык, который настолько же естественен для программирования, как и многие из динамически типизированных.
При этом есть определенные конструкции, которые просто удивительны в динамически типизированных языках. Например, в Tcl
lindex $mylist end-2
Тот факт, что вы передаете "end-2" для указания нужного вам индекса, невероятно лаконичен и очевиден для читателя. Я до сих пор не видел статически типизированный язык, который выполняет такие.
Я думаю, что аргументы такого рода немного глупы: "Вещи, которые обычно были бы уловлены компилятором, такие как имена переменных с ошибками и присвоение переменной значения неправильного типа, не происходят до времени выполнения", да, это верно как PHP разработчик Я не вижу таких вещей, как переменные с ошибками, до времени выполнения, но для меня время выполнения - это шаг 2, в C++ (который является единственным скомпилированным языком, который у меня есть), это шаг 3, после компоновки и компоновки.
Не говоря уже о том, что после нажатия кнопки "Сохранить" уходит всего несколько секунд, когда мой код готов к запуску, в отличие от скомпилированных языков, где это может занять буквально часы. Извините, если это звучит немного сердито, но я устала от того, что люди относятся ко мне как к второму программисту, потому что мне не нужно компилировать мой код.
Аргумент более сложный, чем этот (читайте статью Йегге "Достаточно слабый набор текста" для интересного обзора).
Динамические языки также не обязательно нуждаются в проверке ошибок - вывод типа C#, возможно, является одним из примеров. Точно так же, C и C++ имеют ужасные проверки компиляции, и они статически типизированы.
Основными преимуществами динамических языков являются: а) возможность (которую не обязательно использовать постоянно) и б) закон итераций Бойда.
Последняя причина огромна.
Я думаю, что нам нужны разные типы языков в зависимости от того, чего мы пытаемся достичь или решить с ними. Если нам нужно приложение, которое создает, извлекает, обновляет и удаляет записи из базы данных через Интернет, нам лучше сделать это с одной строкой кода ROR (используя скаффолд), чем писать его с нуля на языке статической типизации. Использование динамических языков освобождает умы от размышлений о
- какая переменная имеет какой тип
- как динамически вырастить строку
- как написать код, чтобы при изменении типа одной переменной мне не приходилось переписывать все функции, которые с ней взаимодействуют
к проблемам, которые ближе к потребностям бизнеса, как
- данные сохраняются / обновляются и т. д. в базе данных, как я могу использовать их для привлечения трафика на мой сайт
В любом случае, одним из преимуществ слабо типизированных языков является то, что нам все равно, какой это тип, если он ведет себя так, как и предполагалось. По этой причине мы имеем типизацию утили в динамически типизированных языках. это отличная возможность, и я могу использовать одни и те же имена переменных для хранения разных типов данных по мере необходимости. Кроме того, статически типизированные языки заставляют вас думать как машина (как компилятор взаимодействует с вашим кодом и т. д. и т. д.), тогда как динамически типизированные языки, особенно ruby / ror, вынуждают машину мыслить как человек.
Вот некоторые из аргументов, которые я использую, чтобы оправдать свою работу и опыт работы с динамическими языками!
Хотя я еще не большой поклонник Ruby, я считаю динамические языки действительно замечательными и мощными инструментами.
Идея, что нет проверки типов и объявления переменных, не слишком большая проблема на самом деле. По общему признанию, вы не можете поймать эти ошибки до времени выполнения, но для опытных разработчиков это не проблема, и когда вы делаете ошибки, они обычно легко исправляются.
Это также заставляет новичков более внимательно читать то, что они пишут. Я знаю, что изучение PHP научило меня быть более внимательным к тому, что я на самом деле печатал, что улучшило мое программирование даже на скомпилированных языках.
Хорошие IDE дадут вам достаточный смысл, чтобы вы знали, была ли переменная "объявлена", и они также попытаются сделать какой-то вывод типа для вас, чтобы вы могли сказать, что такое переменная.
Сила того, что можно сделать с динамическими языками, на самом деле делает их такими интересными, на мой взгляд. Конечно, вы можете делать то же самое на скомпилированном языке, но для этого потребуется больше кода. Такие языки, как Python и PHP, позволяют быстрее разрабатывать и быстрее получать функциональную кодовую базу.
И, к сведению, я постоянный разработчик.NET, и мне нравятся скомпилированные языки. Я использую только динамические языки в свое свободное время, чтобы узнать о них больше и лучше себя как разработчика.
Динамические языки наносят ответный удар
http://www.youtube.com/watch?v=tz-Bb-D6teE
Беседа о динамических языках, о том, что является положительным, и о том, сколько негативов на самом деле не соответствует действительности.
Я думаю, что оба стиля имеют свои сильные стороны. По моему мнению, это или / или мышление наносит вред нашему сообществу. Я работал в архитектурах, которые были статически набраны сверху вниз, и это было хорошо. Моя любимая архитектура предназначена для динамически типизированного на уровне пользовательского интерфейса и статически типизированного на функциональном уровне. Это также поощряет языковой барьер, который обеспечивает разделение пользовательского интерфейса и функций.
Быть циником, может быть просто, что динамические языки позволяют разработчику быть более ленивым и делать вещи, зная меньше об основах вычислений. Хорошо это или плохо - решать читателю:)
Производительность в определенном контексте. Но это только одна среда, которую я знаю, по сравнению с некоторыми другими, которые я знаю или когда-либо использовал.
Smalltalk на Squeak/Pharo с Seaside - гораздо более эффективная и эффективная веб-платформа, чем ASP.Net(/MVC), RoR или Wicket, для сложных приложений. Пока вам не нужно взаимодействовать с чем-то, что имеет библиотеки в одном из них, но не в Smalltalk.
Имена переменных с ошибками отмечены красным в IDE, IntelliSense работает, но не так специфично. Ошибки времени выполнения на веб-страницах - это не проблема, а особенность: один клик для вызова отладчика, один клик для моей IDE, исправление ошибки в отладчике, сохранение, продолжение. Для простых ошибок время кругового обхода для этого цикла составляет менее 20 секунд.
Поставьте себя на место новенького программиста, выбирающего язык для начала, который не заботится о динамике, о статике, о лямбдах, об этом, о чем-то и т. Д.; какой язык вы бы выбрали?
C#
using System;
class MyProgram
{
public static void Main(string[] args)
{
foreach (string s in args)
{
Console.WriteLine(s);
}
}
}
Lua:
function printStuff(args)
for key,value in pairs(args) do
print value .. " "
end
end
strings = {
"hello",
"world",
"from lua"
}
printStuff(strings)
Все это частично сводится к тому, что подходит для конкретных целей и каковы общие личные предпочтения. (Например, это будет огромная база кода, поддерживаемая большим количеством людей, чем может провести разумную встречу вместе? Вам нужна проверка типов.)
Личная часть заключается в обмене некоторых проверок и других шагов на скорость разработки и тестирования (в то время как, вероятно, отказ от некоторой производительности процессора). Есть люди, для которых это освобождает и повышает производительность, а есть люди, для которых это совершенно противоположно, и да, это зависит от особенностей вашего языка. Я имею в виду, что здесь никто не говорит, что Java - это стремительная, краткая разработка, или что PHP - это надежный язык, на котором вы редко будете замечать опечатки.
У меня нет большого опыта работы с динамическими языками в целом, но один динамический язык, который я знаю, JavaScript(он же ECMAScript), я очень люблю.
Ну, подожди, что здесь за обсуждение? Динамическая компиляция? Или динамическая типизация? JavaScript охватывает обе основы, так что, я думаю, я расскажу об обоих:
Динамическая компиляция:
Для начала динамические языки компилируются, компиляция просто откладывается на потом. И Java, и.NET действительно скомпилированы дважды. Однажды на их соответствующие промежуточные языки, и снова, динамически, на машинный код.
Но когда компиляция отложена, вы можете увидеть результаты быстрее. Это одно из преимуществ. Мне очень нравится просто сохранить файл и увидеть мою программу в действии довольно быстро.
Еще одним преимуществом является то, что вы можете писать и компилировать код во время выполнения. Возможно ли это в статически скомпилированном коде, я не знаю. Я предполагаю, что так и должно быть, поскольку все, что компилируется в JavaScript, в конечном итоге является машинным кодом и статически компилируется. Но на динамическом языке это тривиальная вещь. Код можно написать и запустить сам. (И я почти уверен, что.NET может сделать это, но CIL, в который компилируется.NET, динамически компилируется на лету, и это не так тривиально в C#)
Динамическая типизация:
Я думаю, что динамическая типизация более выразительна, чем статическая. Обратите внимание, что я неформально использую термин выразительный, чтобы сказать, что динамическая типизация может сказать больше с меньшими затратами. Вот некоторый код JavaScript:
var Person = {};
Вы знаете, что такое Персона сейчас? Это общий словарь. Я могу сделать это:
Person ["First_Name"] = "Джон"; Person["Last_Name"] = "Smith";
Но это тоже объект. Я мог бы сослаться на любой из этих "ключей", как это:
Person.First_Name
И добавьте любые методы, которые я считаю необходимыми:
Person.changeFirstName = function (newName) {
this.First_Name = newName;
}; Конечно, могут быть проблемы, если newName не является строкой. Это не будет поймано сразу, если когда-либо, но вы можете проверить себя. Это вопрос торговли выразительной силой и гибкостью для безопасности. Я не против добавить код для проверки типов и т. Д. Сам, и мне еще предстоит столкнуться с ошибкой типов, которая доставила мне много горя (и я знаю, что это мало что говорит. Это может быть вопросом времени:)). Однако мне очень нравится эта способность адаптироваться на лету.
Хороший пост в блоге на ту же тему: Python делает меня нервным
Сигнатуры методов практически бесполезны в Python. В Java статическая типизация превращает сигнатуру метода в рецепт: это все дерьмо, которое нужно, чтобы этот метод работал. Не так в Python. Здесь сигнатура метода скажет вам только одно: сколько аргументов вам нужно, чтобы оно работало. Иногда это даже не произойдет, если вы начнете трахать с ** кваргами.
Я люблю и статические и динамические языки. Каждый проект, в котором я участвовал примерно с 2002 года, был приложением C/C++ со встроенным интерпретатором Python. Это дает мне лучшее из обоих миров:
- Компоненты и платформы, составляющие приложение, для данного выпуска приложения являются неизменяемыми. Они также должны быть очень стабильными и, следовательно, хорошо проверенными. Статически типизированный язык является правильным выбором для создания этих частей.
- Схема подключения компонентов, загрузка библиотек компонентов, графические объекты, большая часть графического интерфейса и т. Д. Могут сильно различаться (например, настраивать приложение для клиента) без необходимости изменения какой-либо инфраструктуры или кода компонентов. Динамический язык идеально подходит для этого.
Я считаю, что сочетание языка статической типизации для построения системы и языка динамической типизации для ее настройки дает мне гибкость, стабильность и производительность.
Чтобы ответить на вопрос "Что такое любовь к динамическим языкам?" Для меня это возможность полностью перенастроить систему во время выполнения любым возможным способом. Я вижу язык сценариев как "запускающий шоу", поэтому исполняющее приложение может делать все, что вы пожелаете.
FWIW, компиляция в большинстве приложений не должна занимать часы. Я работал с приложениями длиной от 200 до 500 тысяч строк, которые компилируются за минуты. Конечно, не часы.
Я предпочитаю скомпилированные языки сам. Мне кажется, что инструменты отладки (по моему опыту, которые могут быть не верны для всех) лучше, а инструменты IDE - лучше.
Мне нравится, когда я могу подключить Visual Studio к работающему процессу. Могут ли другие IDE сделать это? Возможно, но я не знаю о них. В последнее время я занимался разработкой PHP, и, честно говоря, не все так плохо. Тем не менее, я предпочитаю C# и VS IDE. Я чувствую, что работаю быстрее и быстрее отлаживаю проблемы.
Так что, может быть, это больше для меня вещь, чем проблема с динамическим / статическим языком?
Последний комментарий... если вы разрабатываете с локальным сервером, сохранение выполняется быстрее, чем компиляция, но часто у меня нет доступа ко всему на моей локальной машине. Базы данных и файловые ресурсы живут в других местах. Проще подключиться по FTP к веб-серверу, а затем запустить мой PHP-код только для того, чтобы найти ошибку и исправить ее, а затем заново выполнить ftp.
Потому что я считаю глупым указывать тип коробки. Тип остается с сущностью, а не с контейнером. Статическая типизация имела смысл, когда тип поля имел прямое влияние на то, как интерпретировались биты в памяти.
Если вы посмотрите на шаблоны проектирования в GoF, вы поймете, что значительная их часть предназначена только для борьбы со статической природой языка, и у них нет никаких оснований вообще существовать в динамическом языке.
Кроме того, я устал от необходимости писать что-то вроде MyFancyObjectInterface f = new MyFancyObject(). СУХОЙ принцип кто-нибудь?
Слабо типизированные языки позволяют гибко управлять вашими данными.
Прошлой весной я использовал VHDL для нескольких классов, и мне нравится их метод представления битов / байтов и то, как компилятор ловит ошибки, если вы пытаетесь назначить 6-битную шину для 9-битной шины. Я попытался воссоздать его в C++, и у меня есть изрядная борьба за то, чтобы аккуратно заставить печатать работать гладко с существующими типами. Я думаю, что Стив Йегге очень хорошо описывает проблемы, связанные с сильными системами типов.
Что касается многословия: я считаю, что Java и C# довольно многословны в целом (давайте не будем выбирать небольшие алгоритмы, чтобы "доказать" свою точку зрения). И да, я написал в обоих. С ++ борется и в той же области; VHDL уступает здесь.
Скупость, кажется, является достоинством динамических языков в целом (я представляю Perl и F# в качестве примеров).
Для меня это вопрос ситуации. Я трачу много времени на написание Perl-кода для веб-сайтов и C++ для графических движков. Две совершенно разные сферы программирования с двумя совершенно разными языками.
В любом случае, динамические языки работают быстрее, потому что я трачу меньше времени на то, чтобы убедиться в наличии инфраструктуры, а больше на актуальную проблему.
Однако статические языки предлагают более тонкую настройку управления, которая может быть необходима в некоторых приложениях, таких как рендеринг графики в реальном времени. Я могу делать вещи в C++, которые работают намного эффективнее и быстрее, чем то, что я написал бы для Perl, но для размера большинства скриптов Perl потеря в эффективности незначительна.
В конце концов, это действительно сводится к постановке проблемы и каковы ваши цели. Если у вас есть много простых вещей, где скорость и эффективность памяти не имеют большого значения, используйте динамический язык. Если у вас есть мегалитический проект, который должен выжать каждый последний цикл из вашей системы, переходите в состояние статического электричества.