Pozwoliłem sobie przenieść dyskusję, w zasadzie jeszcze na nowym silniku nie miałem okazji na taki cherry pick pojedynczych postów do nowego wątku, więc bezwzględnie Cię wykorzystałem.
A teraz po kolei.
@Wired napisał w Smutne nerdy czyli offtop o językach skryptowych:
Skrypt nie funkcjonuje bez programu w ramach którego jest wykonywany, macro w excelu wykonuje funkcje programu excel ale samo ich nie tworzy, automatyzuje jedynie kolejność ich wykonania. Tak samo skrypt BASH w Linuxie, wywołuje elementy istniejące już na miejscu. Nie jesteś w stanie napisać działającego całkowicie niezależnie skryptu.
Wedle Twej definicji wszystko jest skryptem. Dlaczego? Dowolny napisany przez Ciebie program dla dużego systemu operacyjnego jak Windows czy Linux nie może istnieć bez wspomnianego systemu operacyjnego, a nawet kilku rzeczy więcej. Określa się to jako minimalny runtime w skład którego wchodzą podstawowe biblioteki, syscalle oraz to, co OS robi z plikiem wykonywalnym. C++ definiuje nawet w standardzie implementację freestanding (którą głównie kojarzysz z mikrokontrolerów) oraz hosted.
Aby Ci to uświadomić jak to wygląda w normalnym systemie operacyjnym, weźmy na przykład odpalenie typowego pliku wykonywalnego napisanego dajmy na to w C++, dajmy na to pod platformę Linux, czyli elf. System operacyjny czyta plik elf aby dowiedzieć się z czym ma kontakt, typowe użycie tego sprawdzenia, poza ładnym komunikatem, że odpalasz program na aarch64 pod x64 zamiast wywalenia się instrukcji, to jest załadowanie przez kernel handlera 32-bitowe w ramach wstecznej kompatybilności starszych programów. Następnie system operacyjny czytając plik wykonuje mapowania danych stałych na przestrzenie adresowe oczekiwane przez program. To tutaj właśnie system operacyjny ogarnia adresy dla stałych stringów w Twoim programie, ale nawet globalnych, niezainicjonowany, zmiennych. Ciekawostka dla nerdów, z tego powodu długość statycznych tablic na Windowsie jest ograniczona gdyż jego format który ludzie znają jako .exe wabi się PE (Portable Executable) i tam wszystkie indeksy są 16 i 32 bitowe
System operacyjny ustawia również początkową wielkość stosu jaką otrzymasz. I.. Nie, jeszcze nie koniec. Następuje wczytanie bibliotek dynamicznych którym to zajmuje się, delegując pracę do ld, system operacyjny. W typowym Linuxie biblioteka standardowa jest częścią systemu operacyjnego (dla języka C++). Bez niej nic Ci nie będzie działać. Dopiero po tym następuje ustawienie rejestrów, adresów i wczytanie programu. Tak w skrócie.
Dobrze, załóżmy, że nie używamy biblioteki standardowej ani innych zależności, nadpisujemy sobie start (przed main) lub używamy np. Rusta który statycznie linkuje takie rzeczy i dostarcza łatwo swoje biblioteki. W dalszym ciągu jesteś ograniczony do środowiska systemu operacyjnego, pomijając fakt, że de facto OS jest panem życia i śmierci procesu, to bez OSa będziesz ślepy i głuchy. Nie alokujesz pamięci bez wywołania mmap czy sbrk, nie napiszesz do systemu plików (więc też nie dobierzesz się do driverów bez IO aby pisać rzeczy samemu). Nie zrobisz nic.
Mikronoktrolery to osoba kwestia...
Powyższe jest tylko po to aby pokazać Ci, że twa definicja jest po prostu błędna, bo jest generyczna.
@Wired napisał w Smutne nerdy czyli offtop o językach skryptowych:
Program jest niezależny, programując definiujesz obiekty i ich relacje, to są nowe rzeczy, program do działania nie potrzebuje innego programu tak jak skrypt powłoki, czy macro excela.
Wedle tej finalnej definicji, typowy program napisany w Javie nie jest programem. Bo popatrzmy, jak stwierdziłeś, program do działania nie potrzebuje innego programu. Pomijając na chwilę powyższe i odchodząc od tych nudnych, kompilowanych do kodu maszynowego językach, przejdźmy do wspomnianej Javy. Taki program kompilowany do tak zwanego kodu bajtowego - jest to pośredni sposób reprezentacji Twojego programu zawierający instrukcje co program ma robić, lecz nie nadający się do wykonania na procesorze. W tym miejscu przychodzi cały, osobny program w postaci której z implementacji wirtualnej maszyny javy (będę używał skrótu JVM). JVM ładuje Twój program (a tak naprawdę to zestaw plików .class robiąc na nich podobne operacje jakie robi OS, plus jeszcze dokładając pracę klasycznego linkera), alokuje dla niego pamięć, zarządza pamięcią oraz wykonuje... kod. Bajtkod nie jest ogarniany przez procesor, to JVM wiodąc 0xba wie, że jest to instrukcja invokedynamic czyli wywołanie metody po interface. Wszystko dzieje się w jej ramach. Dodatkowo to JVM musi dostarczyć JRE czyli tak jakby Twoją "bibliotekę standardową". Implementacja JRE jest ściśle powiązana z konkretną implementacją JVM gdyż inaczej pewnych rzeczy nie da się zrobić. Dobrym przykładem jest podstawa klasy stringa który musi sięgać do tego, jak w JVM są wyspecyfikowanie stringi (głównie kwestia const pool).
Taka sama uwaga tyczy oczywiście platformy .NET znanej z C#. Oczywiście, istnieją sposoby skompilowania tych języków do formy natywnej (Graal dla Javy, AOT dla C#. Ale po pierwsze, nie są to baseline danych technologii, po drugie wypowiadałeś się o języku per se więc zakładam, że albo chodziło o typowy przypadek użycia albo nie rozgraniczałeś sposobu kompilacji.
@Wired napisał w Smutne nerdy czyli offtop o językach skryptowych:
I to główna różnica bez wchodzenia w głębszą analizę. Z czasem małe programy mające na celu automatyzację pewnych działań i proste czynności zaczęły być przez młodzież bez teorii ze szkoły nazywane skryptami, bo robiły to do czego kiedyś pisano skrypty, ale to nie zmienia definicji.
Jak wskazałem wyżej, Twa definicja łapie jako Twoje pojęcie skryptu prawie... wszystko. I co zabawne:
@Wired napisał w Smutne nerdy czyli offtop o językach skryptowych:
Ogólnie chyba mylisz pojęcie języka interpretowanego z językiem skryptowym
To właśnie Twa definicja, czyli zależność kodu od innego programu jest de facto definicją języka interpretowanego. Interpretacja może zachodzić również na etapie kodu pośredniego (przykład JVM) aczkolwiek zwykle takie ujęcie języków interpretowanych jest dość akademickie.
Ale przejdźmy do kilku ciekawszych tez:
@Wired napisał w Smutne nerdy czyli offtop o językach skryptowych:
JS nie jest językiem skryptowym, i wspomniany node ładnie to udowadnia, bo możesz tworzyć w nim niezależne programy działające gdziekolwiek
Pierwsza część, to jest coś, co mam nadzieję obaliliśmy, więc druga. Node to jest środowisko uruchomieniowe, język nie zadziała gdziekolwiek. Wymaga silnika, czy to na desktopie jak node czy wbudowanego w przeglądarkę. Notabene względem zachowania to node nie różni się niczym od basha. I to, i to jest osobnym programem
@Wired napisał w Smutne nerdy czyli offtop o językach skryptowych:
posiada też mnóstwo elementów nie istniejących w samej przeglądarce jak obiekty
To była dodatkowa uwaga czy co? Bo istnienie dodatkowych rozszerzeń nie jest niczym niezwykłym, przeglądarki względem siebie różnią się dostępnymi funkcjonalnościami języka, a nawet dawniej, tempem z jakim implementowały nowe specyfikacje ecmascript (stąd miałeś początek transpilatorów JS do JS, wtedy nie chodziło o optymalizacje).
wagi o obiektach nie rozumiem bo JS ma obiekty, jest językiem obiektowym, po prostu ma nietypowy ( i trochę głupi) model obiektowy
@Wired napisał w Smutne nerdy czyli offtop o językach skryptowych:
Ogólnie chyba mylisz pojęcie języka interpretowanego z językiem skryptowym, ale w sumie od dawna już JS jest kompilowany, więc co masz na myśli pewien nie jestem.
Zakładam, że masz na myśli kompilację w trakcie uruchomienia (bo termin język kompilowany odnosi się JS -> inny target czyli nie ma mowy o case transpilacji np. TypeScript do JavaScript). To jest cecha środowiska w którym jest uruchamiany, mnij lub bardziej podążająca za specyfikacją. Tak zwany JIT czyli generowanie kodu maszynowego w trakcie interpretacji języka (lecz nie wcześniej, i nie dla całości kodu) to rzecz znana. Tylko to nie jest definicja języka kompilowanego, język kompilowany na początku generuje wynik do innej reprezentacji (na przy…ład Java kompiluje się do kodu bajtowego). Zresztą, wedle Twej definicji to python jest językiem kompilowanym, i wcale nie mam na myśli tutaj JITa który pojawił się niedawno eksperymentalnie. Od bardzo dawna podczas interpretacji cpython generuje wewnętrzny kod bajtowy (czyli kompiluje kod do innej reprezentacji) w celu przyśpieszenia wykonania już raz odwiedzonych plików, aby nie musieć wykonywać parsowania za każdym razem. I tak robi większość języków.
Tak słowem zakończenia, tak ogólnie mówiąc, to język skryptowy to pomieszanie cechy fenomenologicznej czyli głównie bycia technologią interpretowaną (w najbardziej powszechnym sensie, nie akademickim) i behawioralnej czyli używania do prostych zadań, automatyzacji itd. I nie jest to cecha ekskluzywna, to jest język może być poważnym językiem do większych rzeczy ale też skryptowym. Tak żył przez lata perl, a potem python
