Я схильний думати з точки зору особливостей:
Синтаксис:
На основі С чи що у вас є. У Java є синтаксис на основі С. Я настійно рекомендую спробувати щось на зразок Python або Ruby, щоб вивести голову з синтаксису і більше думати з точки зору основ роботи тієї чи іншої мови. Я вважаю, що жоден синтаксис не повинен бути об'ємнішим, ніж на основі С та не має проблемних будівельних блоків навколо білого простору.
Складено проти інтерпретованого w. Збірка-процес проти інтерпретованого / консольного:
Я дуже мало знайомий з питаннями компіляції часу та часу виконання, але я розумію, що там є цілий пакет проблем, про які я рідко замислююся.
Так само є багато інтерпретованих мов, які все ще мають щось із процесу компіляції для роботи всередині віртуальної машини, як це робить Java. Вам доведеться перебудувати, щоб побачити зміни в речах.
А потім є JavaScript і Python, які ви можете виконувати на льоту, командувати командою в консолі в реальному середовищі. Усі три можуть призвести до дуже різних способів написання коду.
Динамічне та суворе введення тексту:
Я схильний розглядати це як компромісні рішення. Коли ви перебуваєте на значно нижчому рівні та продуктивність є критичною, статичне введення має багато сенсу. Я ніколи не розумів цього поняття того, що одна людина є "безпечнішою", ніж інша, але я придумала дуже пластичну / динамічну мову, де ви просто дізнаєтесь, як працює система набору тексту та чого очікувати в основному. Шенігани типу рідко хвилюють мене в JS. Деяким чином гнучкість може зробити речі більш надійними, хоча, мабуть, на дотик більш прихованим для більш молодшого рівня, якщо ви не знаєте про деякі отвори в мові.
Область блоку на рівні порівняно з функцією:
Блок-рівень є найпоширенішим (що-небудь між {} у більшості мов синтаксису на основі с). Область JavaScript побудована навколо функцій (які також використовуються для створення об'єктів настільки ефективно). Існує також велика різниця у тому, який доступ ви маєте від внутрішнього простору до зовнішнього. Я не знайомий з іншими схемами оцінювання, але впевнений, що вони існують.
Класичний OOP проти Prototypal OOP проти майже OOP (структури в C?) Проти Non-OOP:
Навіть у ООП на базі класів є велика кількість варіацій. Чи можете ви робити численні спадкування (ew, добре з надлишком, ew), визначати інтерфейси тощо ...
У JavaScript у нас є свого роду приголомшений гібридний прототиповий OOP, де об'єкти значно простіші, дуже мутабельні, але ми все ще маємо можливість відокремити інтерфейс від внутрішніх проблем, що є IMO - важливим аспектом інкапсуляції.
Справа в OOP полягає в тому, що дійсно є багато речей, які ви можете зняти, які по суті є орієнтованими на ООП, а технічно не є OOP. Звичайно, існують пуристи, але наприкінці дня «Шаблони дизайну» стосуються досягнення певних абстракцій, які добре працюють у певних ситуаціях. Не будьте занадто швидкі, щоб вважати, що ідеї з мовою, що базується на ООП, не мають користі в чомусь більш орієнтованому на процедуру. І я не кажу про JavaScript. Це зовсім не обмежено його густою версією прототипу OOP, заснованої на прототипі.
Функції першого класу:
Якщо не мати цих мов, то мені важко відмовитися. Ви можете передавати функції приблизно так, як це були дані для використання в інших контекстах. Це робить схеми обробки подій, зокрема, дуже простою у здійсненні, але вона також дуже легко адаптує мову до роботи так, як ви хочете. Я підозрюю, що більше ніж усе, що я підозрюю, те, що зробило JavaScript успіхом, що його остаточно, незважаючи на те, що він був розроблений за два тижні і отримав наближений до Java синтаксис, як по ньому, як маркетингова схема.
Закриття:
Я не впевнений, де ведуться дебати щодо Java, але я знаю, що багато Java розробників вимагали цієї функції рік-два тому. Коли мова не закривається, коли функція закривається, все, що якимось чином посилається на матеріали зсередини цієї функції, не зможе отримати доступ до неї, оскільки вона зібрала сміття. При закритті контекст виконання пов'язаний таким чином, що якщо ви можете посилатись на матеріали, що знаходяться в тій закритій функції, з іншого діапазону, наприклад, у поверненому об'єкті або функції, ви отримуєте ці параметри такими, якими вони були, коли функція була закрита. Це схоже на заклинювання вашої ноги у дверях сміття, хоча я підозрюю, що це реалізоване більше, як копії цих камер, зроблених у місцевих касах відповідної організації.
Жорсткий / Суворий / Безпечний проти надання вам усієї мотузки, яку хочете:
JS devs та Java devs мають тенденцію взагалі не розуміти один одного, і я думаю, що це має багато спільного з двома мовами, що падають на майже протилежні сторони цього конкретного дизайнерського спектру. Я не хочу, щоб ти захищав мене від себе чи від інших чортів моєї команди. Я хочу зробити набагато більше в набагато меншому коді і робити все це дуже різними (але послідовними для даного домену) способами залежно від ситуації. Існують абсолютно компрометації обох, і багато мов, як правило, більше падають на середину.
