> >>> No dobrze. I Python też jest kompilowany do kodu pośredniego.
> >>> Zatem według Twojej definicji nie jest skryptowy?
> >> Gdzie ty znalazłeś taką informację że jest kompilowany do kodu
> >> pośredniego? Mam na myśli czystego Pythona. Chętnie poznam jakiś przykład
> >
> > Na przykład tutaj:
> > https://docs.python.org/3/glossary.html#term-bytecod
e
> >
> > "Python source code is compiled into bytecode, the internal representation of a
Python program in the CPython interpreter"
>
> A przeczytałeś całość, zakładam że nie bo byś wiedział że kod pośredni
> jest tworzony tylko niektórych funkcji.

Nie rozumiem. Których funkcji?
Z tego co wiem, Python zawsze generuje .pyc, który w całości jest kodem pośrednim.

Ale jeśli nawet przyjąć że
> całość - podobnie jak to się dzieje w przypadku np Javy to wspomniałem
> już wcześniej w postach cos takiego: "Podział na języki skryptowe i
> kompilowane jest raczej prosty. Bardziej skomplikowane jest rozróżnienie
> języka skryptowego i języka który działa na maszynie wirtualnej - tj
> Java .NET które są świetne ale potrzeba do nich środowiska
> uruchomieniowego."

Jest "bardziej skomplikowane" tylko wtedy, jeśli się przyjmie jakąś dziwną,
niewysłowioną definicję określenia "języki skryptowe".

C# i Java nie są "językami skryptowymi", bo ich przeznaczeniem nie jest pisanie
skryptów.


> >> - Brak kodu binarnego wynikającego bezpośrednio z twojego skryptu
> >
> > No to Python jest tutaj kontrprzykładem.
> Nie jest a dlaczego nie jest masz wyjaśnione to wyżej

Nadal nie rozumiem.

> >>> A co jeżeli przed wykonaniem programu najpierw go skompiluje i zapisze w jakimś
swoim cache'u i wykona wersę skompilowaną?
> >>> (Tak np. robi GUILE)
> >>>
> >> Nie używałem tego nie wiem. Ale jak to działa jak JTL to to nic nie
> >> zmieni, bo nadal będzie działać w odizolowanym środowisku. Rozumiem że
> >> sugerujesz że to działa inaczej?
> >
> > Co to jest JTL?
> Sorki miałem na myśli JIT-kompilatory tj np. NodeJS

OK, to teraz jeszcze raz odnoszę się do zdania
"to nic nie zmieni, bo nadal będzie działać w odizolowanym środowisku".

To, o czym piszesz "odizolowane środowisko" albo jego brak, nazywa się "środowiskiem
natywnym". Na przykład C++ i C to języki, które typowo są kompilowane do kodu
natywnego. Natomiast C# i Java typowo nie są kompilowane do kodu natywnego, tylko do
kodu bajtowego.

I to nie ma absolutnie żadnego związku z "byciem językiem skryptowym"
> > No to załóżmy, że tworzy wyizolowane środowisko. To co wtedy?
> >
> No to i tak dla mnie pozostanie to próbą stworzenia najprawdopodobniej
> języka skryptowego bazującego na C

No nie. Interpreter implementuje język C w 100% zgodny ze specyfikacją.
Więc to jest język C.


> > Nie zauważam.
> > Zauważam, że języki skryptowe służą do pisania skryptów.
>
> To ja zadam pytanie teraz co według ciebie jest skryptem/a co zwykłym
> tekstem napisanym.

Na Wikipedii było, już raz tutaj wklejone:

"Skrypty - programy napisane w językach skryptowych, przeznaczone do wykonywania w
specjalnych środowiskach uruchomieniowych automatyzujących wykonywanie zadań [1],
które alternatywnie mogą być wykonywane jedno po drugim przez użytkownika. "

Czyli są to ciągi instrukcji w rodzaju:

zrób to
zrób tamto
zrób siamto
zrób owamto

(i ktokolwiek kiedykolwiek używał instrukcji sterujących w bashu, wie, jak bardzo się
ten język stara tego nie ułatwiać)

Ewentualnie można powiedzieć, że skryptem jest to, co pisał np. Szekspir.
Że się Poloniusz chowa za zasłonę żeby podsłuchać Hamleta, Hamlet go zabija i Ofiela
płacze.

Natomiast "zwykły tekst" w ogólności nie jest ciągiem instrukcji.

> > A to, czy te skrypty są przed uruchomieniem kompilowane przez środowisko, czy
interpretowane, jest szczegółem, który jest dla mnie niewidoczny, i który bynajmniej
mnie nie obchodzi.
>
> Podkreślam i powtarzam ciężko jest odróżnić sposób wykonywania kodu
> pośredniego tak jak to ma np Java, .NET od języka interpretowanego
> zwanych zazwyczaj skryptowymi idąc nazewnictwem z WIKIPEDII

Nie "zwanych zazwyczaj". Mylisz pojęcia. Są dwa osobne artykuły.
To, że języki skryptowe są zazwyczaj implementowane w postaci interpreterów nie
sprawia, że Javę czy C# łatwo jest pomylić z bashem.
Wikipedia nigdzie nie twierdzi tego, że "skryptowość" języka ma jakikolwiek związek
ze sposobem jego implementacji. A jeżeli twierdzi, to pokaż mi proszę cytat.

> Różnica między nami jest taka że ty uważasz że wystarczy użyć narzędzia
> typu JIT kompilator i to będzie tak samo działało jak tradycyjne języki
> kompilowane - bo od nich zaczęliśmy dyskusje.

Nie. Nie uważam tak. Uważam, że jeżeli użyjemy narzędzia typu JIT, to programy,
względem których tego narzędzia użyjemy, będą kompilowane. Bo faktycznie będą. Bo JIT
to jest kompilator, czyli coś co kompiluje. A "kompilowany" to imiesłów
przymiotnikowy bierny, pochodzący od słowa "kompilować". Zatem jeżeli będziesz
kompilował X, X będzie kompilowane.

Używa się tego inaczej, niż "tradycyjnych języków kompilowanych", bo w ich przypadku
to programista musi wywołać kompilator.

Ale to, czy język jest, czy nie jest kompilowany, nie ma żadnego związku z jego
"skryptowością".

> Potem jak już zrozumiałeś mój punkt widzenia że rozdzielam pojęcia
> języki skryptowe a kompilowane proszę o to cytat "Mnie się zdaje, że
> utożsamiasz ze sobą te dwie rzeczy.
> Tzn. rozróżniasz na "języki skryptowe" i "języki kompilowane"
> [podczas gdy nic nie stoi na przeszkodzie, żeby języki skryptowe były
> kompilowane]
>
> Odpisałem ci na to:
> "Masz racje nie stoi nic na przeszkodzie. Fakt jednak jest taki że
> obecne rozwiązania takie jak JTL czy NodeJS czy inne podobne rozwiązania
> nie kompilują tego skryptu a jedynie dają możliwość jego uruchomienia po
> za natywnym środowiskiem a to jest różnica"
>
> Gdze pisząc JTL miałem na myśli JIT na co słusznie zwróciłeś uwagę.
>
> Więc jeśli znów zapytasz mnie czy według mnie Java czy .NET można uznać
> za skryptowe odpowiem po raz kolejny - nie - a wynika to z różnic ich
> implementacji.

Tak, ale nie powiesz, jakie to różnice, tylko powiesz, że to ciężkie do wyjaśnienia.

A tymczasem to jest bardzo łatwe do wyjaśnienia. I nie ma żadnego związku z
implementacją.