Я склонен думать с точки зрения особенностей:
Синтаксис:
C-Based или что-у-ты. Java имеет синтаксис на основе языка C. Я настоятельно рекомендую попробовать что-то вроде Python или Ruby, чтобы вывести голову из синтаксиса и больше думать о принципах работы данного языка. Я придерживаюсь мнения, что никакой синтаксис не должен быть более объемным, чем на основе C, и у него нет проблем с компоновкой блоков вокруг пробела.
Скомпилировано и интерпретировано w. Процесс сборки и интерпретация / Консоль:
Я очень мало знаком с проблемами времени компиляции и среды выполнения, но я понимаю, что есть целый пакет проблем, о которых я редко думаю.
Аналогичным образом, существует множество интерпретируемых языков, в которых все еще есть что-то вроде процесса компиляции для работы внутри виртуальной машины, как это делает Java. Вы все еще должны восстановить, чтобы увидеть изменения в вещах.
Кроме того, есть JavaScript и Python, которые вы можете выполнять на лету, команда за командой в консоли в реальной среде. Все три могут привести к совершенно разным способам написания кода.
Динамическая и строгая типизация:
Я склонен рассматривать эти два как компромисс дизайна. Когда вы находитесь на гораздо более низком уровне и производительность критична, статическая типизация имеет большой смысл. Я никогда не понимал этого понятия о том, что одно «безопаснее» другого, но я придумал очень пластичный / динамичный язык, где вы просто изучаете, как работает система набора текста и чего ожидать в принципе. Тип Shenanigans редко беспокоит меня в JS. В некотором смысле гибкость может сделать вещи более надежными, хотя по общему признанию это немного более загадочно для более опытного разработчика младшего уровня, если вы не знаете о некоторых пробелах в языке.
Область действия на уровне блоков и Область функций по сравнению с?
Уровень блоков является наиболее распространенным (что-нибудь между {} в большинстве языков синтаксиса на основе c). Область видимости JavaScript построена вокруг функций (которые также используются для эффективного создания объектов). Существует также много различий в том, какой у вас доступ из внутренней области видимости к внешней. Я не знаком с другими схемами определения объема, но уверен, что они существуют.
Классический ООП против прототипного ООП против почти ООП (структура в C?) Против не ООП:
Даже в ООП на базе классов есть много возможностей для вариаций. Можете ли вы сделать множественное наследование (ew, хорошо в избытке, ew), определить интерфейсы и т.д ...
В JavaScript у нас есть своего рода задержанный гибридный прототип ООП, где объекты значительно более просты, легко изменяемы, но у нас все еще есть возможность отделить интерфейс от внутренних проблем, что, по мнению IMO, является важным аспектом инкапсуляции.
Особенность ООП состоит в том, что на самом деле есть много вещей, которые вы можете извлечь, которые по существу ориентированы на ООП, не будучи технически ООП. Конечно, есть пуристы, но в конце концов, шаблоны проектирования - это достижение определенных абстракций, которые хорошо работают в определенных ситуациях. Не спешите предполагать, что идеи из языка ООП не имеют смысла в чем-то более ориентированном на процедурный процесс. И я не говорю о JavaScript. Он ничуть не ограничен своей глупой версией ООП-парадигмы на основе прототипа.
Первоклассные функции:
Не имея их на языке, мне трудно сдаться. Вы можете передавать функции так, как будто они были данными для использования в других контекстах. Это делает, в частности, схемы обработки событий очень простыми для реализации, но также очень легко адаптирует язык для работы так, как вы хотите. Это больше, чем я подозреваю, то, что сделало JavaScript тем успехом, которого он достиг, несмотря на то, что был разработан за две недели и получил приближенный к Java синтаксис как маркетинговую схему.
Затворы:
Я не уверен, где спор о Java, но я знаю, что многие разработчики Java требовали этой возможности год или два назад. В незамкнутом языке, когда функция закрывается, все, что каким-либо образом может ссылаться на что-то изнутри этой функции, не сможет получить к ней доступ, потому что она была собрана сборщиком мусора. В замыкании контекст выполнения ограничен таким образом, что если вы можете ссылаться на вещи внутри этой закрытой функции из другой области видимости, как в возвращенном объекте или функции, вы в основном получаете эти переменные такими, какими они были, когда функция закрывалась. Это похоже на заклинивание ногой в дверях сборки мусора, хотя я подозреваю, что это реализовано больше как копии тех переменных, превращенных в локальные переменные ссылающейся сущности.
Жесткий / Строгий / Безопасный против Дать вам всю веревку, которую вы хотите:
Разработчики JS и Java, как правило, вообще не понимают друг друга, и я думаю, что это во многом связано с двумя языками, которые находятся на почти противоположных сторонах этого конкретного спектра дизайна. Я не хочу, чтобы вы защищали меня от себя или от других разработчиков в моей команде. Я хочу сделать намного больше в гораздо меньшем количестве кода и сделать все это очень разными (но последовательными для данного домена) способами в зависимости от ситуации. Есть оба компромисса, и многие языки имеют тенденцию падать в середине.
