Jaka jest różnica między językiem skryptowym a normalnym językiem programowania?

Jaka jest różnica między językiem programowania a językiem skryptowym? Rozważmy na przykład C kontra Perl.

Czy jedyną różnicą jest to, że języki skryptowe wymagają tylko interpretera i nie wymagają kompilacji ani łączenia?

Myślę, że różnica ma znacznie więcej wspólnego z zamierzonym użyciem języka.

Na przykład Python jest interpretowany i nie wymaga kompilacji i łączenia, tak jak Prolog. Oba z nich sklasyfikowałbym jako języki programowania.

Języki programowania są przeznaczone do pisania oprogramowania. Są przeznaczone do zarządzania dużymi projektami. Prawdopodobnie mogą wywoływać programy, czytać pliki itp., Ale mogą nie być w tym tak dobrzy jak język skryptowy.

Języki skryptowe nie są przeznaczone do tworzenia oprogramowania na dużą skalę. Ich składnia, funkcje, biblioteka itp. Koncentrują się bardziej na szybkim wykonywaniu małych zadań. Oznacza to, że czasami są bardziej „hackerscy” niż programowanie języków i mogą nie mieć tych samych fajnych funkcji. Są zaprojektowane do wykonywania zautomatyzowanych często wykonywanych zadań, takich jak iteracja po zbiorze plików lub wykonywanie zadań sysadmin.

Na przykład Bash nie radzi sobie dobrze z arytmetyką, co prawdopodobnie spowodowałoby, że pisanie w nim dużego oprogramowania byłoby koszmarem.

Jako swego rodzaju wzorzec: nigdy nie napisałbym odtwarzacza muzycznego w perlu, chociaż prawdopodobnie mógłbym. Podobnie nigdy nie próbowałbym używać C ++ do zmiany nazw wszystkich plików w danym folderze.

Ta linia staje się coraz bardziej rozmyta. JavaScript, z definicji język programowania „skryptowego”, jest coraz częściej wykorzystywany do tworzenia „aplikacji internetowych”, które są bardziej w dziedzinie oprogramowania. Podobnie, Python początkowo pasuje do wielu cech języka skryptowego, ale coraz więcej oprogramowania jest rozwijane przy użyciu Pythona jako podstawowej platformy.

Klasyczny artykuł na temat języków skryptowych to Skrypty Johna K. Ousterhouta : Programowanie na wysokim poziomie dla XXI wieku , opublikowane w Computer 31 (3), 1998. Z jednej strony rozróżniał języki skryptowe od języków programowania systemowego inny.

Ousterhout scharakteryzował języki programowania systemu jako ewoluujące w celu zastąpienia języków maszyn do programowania. Ukrywają nużące szczegóły, takie jak przypisywanie rejestrów i sekwencje wywoływania podprogramów, zapewniają proste konstrukcje do zapisywania pętli i innych popularnych idiomów sterowania, a także egzekwują dyscyplinę pisania. Zazwyczaj są one implementowane przez kompilator (z wyprzedzeniem). Te języki są przeznaczone do pisania oprogramowania od podstaw. Przykładami są C, C ++ i Java.

Natomiast języki skryptowe, według Ousterhout, zaczynają się od założenia, że ​​istnieją już przydatne programy, zwykle napisane w systemowych językach programowania. Języki skryptowe, takie jak Perl, Python, Tcl, Visual Basic i Unix, zapewniają narzędzia do łączenia istniejących programów w nowe programy. Ousterhout scharakteryzował języki skryptowe jako „beztypowe” (w tym to, co wielu nazywa dynamicznym pisaniem) i kładąc nacisk na szybki rozwój; są one zwykle realizowane przez tłumaczy.

Teraz należy uważać, aby nie zakładać, że model koncepcyjny jednego autora jest autorytatywny. Chociaż my, informatycy, lubimy udawać, że jesteśmy matematykami, podając precyzyjne definicje wszystkich terminów, w praktyce większość terminologii komputerowej jest zbudowana społecznie z rozmytymi i niejednorodnymi znaczeniami; na bardzo wysokim poziomie istnieje szorstki konsensus w sprawie większości terminów, ale szczegóły często zależą od tego, kto pisze. Tak więc weźcie jego artykuł, moją odpowiedź i wszystkie inne odpowiedzi tutaj z dużą kupą soli.

Osobiście zakwestionowałbym istnienie „normalnego” języka programowania, jak to wyrażasz w swoim pytaniu. Myślę jednak, że koncepcja, którą próbujesz przekazać, odpowiada mniej więcej systemowym językom programowania Ousterhout.

Wszystkie języki skryptowe są również językami programowania. Odwrotna sytuacja nie jest prawdą. Języki, które „wymagają tylko tłumacza”, są tłumaczonymi językami (w przeciwieństwie do języka skompilowanego - należy pamiętać, że niektóre języki, takie jak Java, należą do obu kategorii).

Język klasyfikowany jako język skryptowy oznacza, że ​​jest przydatny jako język „kleju”. Skrypty nie są zwykle w pełni funkcjonalnymi programami, lecz wypełniają luki między innymi programami.

Skrypty są zwykle używane do łączenia wielu programów razem, w celu bardzo szybkiego / łatwego wykonywania zadań służebnych, a nawet w środowisku osadzonym, w którym problemy dotyczące wydajności i bezpieczeństwa zostały streszczone na język niższego poziomu. Języki skryptowe kładą nacisk na skrócenie czasu opracowywania, dlatego powodem jest większość interpretacji i bardzo wysoki poziom.

Zestaw „języków skryptowych” jest podzbiorem zestawu „języków programowania”. Różnica między C i Perl polega na różnicy między językiem programowania systemowego a językiem aplikacji oraz między językiem interpretowanym a językiem kompilowanym.

Języki programowania systemu są niskiego poziomu i zorientowane na zarządzanie pamięcią, przewidywalne operacje we / wy i tak dalej. Języki aplikacji są ukierunkowane na szybkie rozwiązywanie problemów wyższego poziomu, takich jak „odczyt ustawień z pliku, otwarte gniazdo i przetwarzanie żądań zgodnie z ustawieniami”.

Tak więc języki aplikacji są zwykle na wyższym poziomie niż języki systemowe, tj. Zapewniają dużą liczbę wbudowanych funkcji abstrakcji i pomocników i często dodają pewnego rodzaju automatyczne zarządzanie pamięcią.

Programy w skompilowanych językach są całkowicie przetwarzane na jakiś kod przed wykonaniem programu. Języki skryptowe są tłumaczone dynamicznie w trakcie wykonywania i często zawierają funkcje do dynamicznego generowania kodu oraz dołączania plików z kodem źródłowym.

Dlatego wszystkie języki skryptowe są językami aplikacji, ale nie jest to prawda. Języki systemowe są zawsze językami kompilowanymi, ponieważ języki skryptowe zwykle zawierają funkcje, których wdrożenie nie jest pragmatyczne pod względem samego języka. Należy jednak pamiętać, że różnica w skryptowaniu (interpretacji) / kompilacji dotyczy bardziej implementacji: w niektórych językach mogą istnieć oba typy implementacji, jak w przypadku haskell.

Inne obejmowały atrybuty, które zwykle kojarzone są z językami skryptowymi i językami innymi niż skryptowe. Jest to pomocne w zrozumieniu, co ludzie mają na myśli, gdy używają terminu „język skryptowy”, ale uważam, że ważniejsze jest zrozumienie, że po prostu nie ma dokładnie określonej granicy: dwie osoby posiadające wiedzę mogą nie zgodzić się, czy dany język X jest język skryptowy. Termin „język skryptowy” jest jednak użyteczny, ponieważ istnieje szeroka zgoda co do języków, które znajdują się daleko poza granicami.

Porównaj „samochód rodzinny” vs. „samochód sportowy” lub „magazyn” vs. „gazeta”. Śmiem twierdzić, że trudno byłoby wymyślić w 100% niezawodną zasadę, aby odróżnić każdy samochód rodzinny od każdego samochodu sportowego, który można uogólnić (co oznacza, że ​​zasadniczo nie sprowadza się do wyliczenia wszystkich istniejących samochodów w każdej kategorii) i przynajmniej potencjalnie obiektywny ( co oznacza, że ​​byłby do przyjęcia dla wszystkich). Ale te terminy są nadal przydatne w praktyce, ponieważ chociaż istnieją pewne przypadki, które trudno rozstrzygnąć, wiele samochodów jest wyraźnie w jednej kategorii, a nie w drugiej.

Różnica, o której jeszcze nie wspomniałem, polega na tym, że przy stosowaniu zgodnie z przeznaczeniem, czas wykonywania większości skryptów będzie zdominowany przez operacje „makroskopowe”, a wydajność operacji mikroskopowych nie będzie miała znaczącego wpływu na ogólny czas wykonania. Na przykład, jeśli program animujący śledzenie promieni może zawierać język skryptowy z instrukcją „renderowania obrazu”, skrypt do wygenerowania 240 klatek animacji może spędzić cztery godziny w instrukcji „renderowania obrazu”, a w sumie cztery sekundy robią wszystko inne. Nawet gdyby przyspieszyć wszystko poza silnikiem renderowania milion razy, miałoby to mniejszy wpływ na ogólną wydajność niż przyspieszenie silnika renderowania o 0,1%.