7 причини, поради които рамките са новите програмни езици

През 80-те години най-лесният начин да започнете битка между маниаци е да обявите, че вашият любим език за програмиране е най-добрият. С, Паскал, Лисп, Фортран? Програмистите прекараха часове, обяснявайки точно защо техният конкретен начин за създаване на клауза if-then-else е по-добър от вашия начин.

Това беше тогава. Днес битките, включващи синтаксис и структура, до голяма степен са приключили, защото светът се е сближил по няколко прости стандарта. Разликите между точка и запетая, къдрави скоби и какво ли още не в C, Java и JavaScript са незначителни. Интересни дебати за въвеждане и затваряне все още съществуват, но повечето са спорни, защото автоматизацията запълва празнината. Ако не ви харесва да посочвате тип данни, има голяма вероятност компютърът да може да направи заключение точно какво сте имали предвид. Ако вашият шеф иска JavaScript, но вие харесвате Java, крос-компилаторът ще преобразува цялата ви статично набрана Java в умален JavaScript, готов за работа в браузър. Защо да се борим, когато технологиите са на гърба ни?

Днес интересното действие е в рамки. Когато седнах с други преподаватели в университета „Джон Хопкинс“, за да планирам нов курс, рамките доминираха в разговора. Angular по-добър ли е от Ember? Всичко това ли е Node.js?

Създадохме анкетен курс, който да изследва архитектурата на най-важните софтуерни пакети, които са в основата на Интернет. Това беше центърът на действието, достоен за анкетен курс, който ще изследва архитектурата на най-важните софтуерни пакети, опасващи днешния Интернет.

В този смисъл рамките са новите езици за програмиране. Те са мястото, където се намират най-новите идеи, философии и практически съвременни кодове. Някои пламват, но много от тях се превръщат в новите основни градивни елементи на програмирането. Ето седем аспекта, подхранващи рамковата тенденция - и превръщайки фреймворка в новото любимо огнище за битки с маниаци.

Повечето кодиращи са низките API

Имаше време, когато писането на софтуер означаваше да разгърнете всичките си познания по езика за програмиране, за да извлечете максимума от кода. Имаше смисъл да се овладеят сложността на указателите, функциите и обхвата - качеството на кода зависи от правилното действие. В наши дни автоматизацията се справя с голяма част от това. Ако оставите безполезни изявления в кода, не се притеснявайте. Компилаторът премахва мъртъв код. Ако оставите указатели висящи, събирачът на боклук вероятно ще го разбере.

Освен това практиката на кодиране е различна сега. Повечето кодове вече са дълга линия от API повиквания. Има случайно преформатиране на данните между извикванията на API, но дори тези задачи обикновено се обработват от други API. Няколко късметлии успяват да напишат интелигентен, биещ бит, жонглиращ с показалеца код за червата на нашите машини, но повечето от нас работят с по-високите слоеве. Ние просто изпълняваме тръба между API.

Поради това е по-важно да разберете как се държи API и какво може да направи. Кои структури от данни приема? Как се държат алгоритмите, когато наборът от данни нараства? Въпроси като тези са по-важни за днешното програмиране, отколкото за синтаксиса или езика. Всъщност сега има редица инструменти, които улесняват извикването на рутина на един език от друг. Сравнително лесно е например да свържете C библиотеки с Java код. Разбирането на API е това, което има значение.

На раменете на гиганти си струва да застанете

Представете си, че сте станали ученици на Ерланг или друг нов език. Вие решавате, че той предлага най-добрата платформа за писане на стабилно приложение без грешки. Това е хубаво настроение, но може да отнеме години, докато пренапишете целия код, наличен за Java или PHP, на най-новия си език по избор. Разбира се, вашият код може да се окаже драстично по-добър, но струва ли си допълнителното време?

Рамките ни позволяват да използваме упоритата работа на онези, които са дошли преди нас. Може да не ни хареса избраната от тях архитектура и да спорим относно подробностите за изпълнението, но е по-ефективно да заглушим оплакванията си и да намерим начин да живеем с разликите. Много по-лесно е да наследявате всичко добро и лошо на кодовата основа чрез рамка. Вземането на мачо маршрута, като пишете всичко сами на любимия си нов език, а не на една от най-популярните му рамки, няма да ви позволи да се насладите на крема от новия си избор толкова бързо, колкото просто да отложите на производителите на рамки и техните API.

Познаването на архитектурата е от значение, а не синтаксисът

Когато по-голямата част от кодирането нанизва API повиквания, няма много предимство в изучаването на идиосинкразиите на езика. Разбира се, бихте могли да станете експерт по това как Java инициализира статични полета в обектите, но би било много по-добре да разберете как да използвате силата на Lucene или JavaDB или някаква друга купчина код. Можете да прекарате месеци в размисли за оптимизиращите рутини на компилаторите Objective-C, но изучаването на тънкостите на най-новата основна библиотека на Apple наистина ще накара вашия код да изкрещи. Ще научите много по-нататък придирчивите детайли на рамката, отколкото синтаксиса на езика, на който се основава рамката.

Повечето от нашия код прекарва по-голямата част от времето във вътрешните цикли на библиотеките. Получаването на коректни подробности за езика може да помогне, но знанието какво се случва в библиотеките може да се изплати драстично.

Доминират алгоритмите

Изучаването на език за програмиране може да ви помогне да жонглирате със скритите данни в променливите, но това ви отвежда само дотук. Истинското препятствие е да се коригират алгоритмите и те обикновено се определят и прилагат от рамките.

Много програмисти разбират, че е опасно и разточително да отделяте време за повторно внедряване на стандартни алгоритми и структури от данни. Разбира се, може да сте в състояние да го настроите малко според вашите нужди, но рискувате да направите фини грешки. Рамките са широко тествани през годините. Те представляват нашата колективна инвестиция в софтуерна инфраструктура. Не са много примерите, когато има смисъл да „излезете от мрежата“, да хвърлите настрана тежката работа на другите и да изградите алгоритмична кабина със собствените си две ръце.

Правилният подход е да проучите рамките и да научите как да ги използвате във възможно най-голяма полза. Ако изберете неправилна структура от данни, бихте могли да превърнете линейна работа в такава, която отнема време, което е квадратична функция от размера на входа. Това е голяма караница, след като станете вирусни.