W dniu sobota, 4 stycznia 2020 02:35:03 UTC+1 użytkownik J-23 napisał:
> >>>> Nie będę się tu rozpisywał bo to raczej większość piszących powinna
> >>>> wiedzieć jak działają takie środowiska w językach typu .NET, Java i o
> >>>> takie środowiska mi chodzi. Teraz czym się różni interpreter Pythona? I
> >>>> tutaj zaczynają się schody :) jest to do wytłumaczenia ale jest to dość
> >>>> zawiłe.
> >>>
> >>> I nie ma najmniejszego znaczenia.
> >>>
> >>
> >> Ma bo zarówno .Net i Java są kompilowane do kodu pośredniego (i to
> >> właśnie jest główna różnica od języków tzw skryptowych)
> >
> > 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"

> >>> Nie. Mówię właśnie o używaniu języka.
> >> Nie bierzesz różnic w działaniu poszczególnych języków a to właśnie te
> >> różnice sprawiają że jedne nazywamy skryptowymi a te drugie kompilowanymi
> >
> > Piszesz tak, jakby skryptowość była czymś przeciwnym do "bycia kompilowanym".
> > A tymczasem nawet artykuł na Wikipedii, który podesłałeś, tak nie twierdzi.
> >
> Bo działą to odmiennie nawet sam przyznałeś cytuje "Proszę. Już sam
> fakt, że istnieją dwa odrębne hasła dla "języków skryptowych" i "języków
> kompilowanych" świadczy poniekąd o tym, że to nie są synonimy."

Błędnie napisałem. Miałem na myśli "języków skryptowych" i "języków interpretowanych"
(bo to było w kontekście tych haseł do Wikipedii)

> > W pewnym sensie można mówić o opozycji "kompilowania vs. interpretacji".
> > Ale to jakiś szczegół techniczny, który nie ma żadnego związku z samym językiem,
a jedynie z narzędziami wykonawczymi.
> No tych szczegółów jest kilka (Wymienie dwa ręsztę doczytaj)
> - Wyizolowane środowiska pracy

Jak uruchamiasz program w C w maszynie wirtualnej, to też izolujesz środowisko pracy.

> - Brak kodu binarnego wynikającego bezpośrednio z twojego skryptu

No to Python jest tutaj kontrprzykładem.

> > Przykładowo, pierwsze implementacje JavaScriptu to były interpretery.
> > Teraz przeglądarki mają swoje JIT-kompilatory, które generują kod maszynowy.
> Widziałeś kiedyś taki kod maszynowy? Zakładając że twój skrypt będzie
> wynosił 1% wielkości wynikowego pliku binarnego to 99% będzie się
> powtarzać bo jest tam mówiąc w uproszczeniu środowisko uruchomieniowe.
> Niech jako przykład posłuży .nodejs od JavaScriptu z Pythonem jest
> prawie że identycznie.
> > Mnie z punktu widzenia użytkownika języka (albo użytkownika programu) w ogóle to
nie obchodzi.
> Z punktu widzenia użytkownika programu zgoda ale z punktu użytkownika
> języka (programisty) obchodzi bardzo bo musi być zgodność co do użytych
> bibliotek i wersji pythona

Zgodność musi być, ale jeżeli narzędzia to załatwiają, ja się nie mam czym martwić.

> > 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?

> > No to weźmy sobie takie coś:
> > https://gitlab.com/zsaleeba/picoc
> > To jest interpreter języka C.
> > I teraz, czy istnienie tego interpretera sprawia, że C staje się językiem
skryptowym?
> >
> Nie używałem ale już z opisu widać z tego co się domyśliłem, bo jak to
> działa to bym musiał sprawdzić że działa to bezpośrednio na sprzęcie
> więc domyślam się że nie tworzy żadnego izolowanego środowiska - w tej
> chwili gdybam bo tak jak mowie tego nie używałem.

No to załóżmy, że tworzy wyizolowane środowisko. To co wtedy?

> Swoją drogą obejmuje to któryś pełny standard C?

Załóżmy że tak.
(Podejrzewam, że tak, bo C nie jest jakimś kosmicznym monstrum)

> > Tzn. skryptowość jest "cechą interpretera języka"?
> > Czyli czy wg Ciebie jest tak:
> > 1. języki można podzielić na kompilowane i interpretowane
> > 2. niektóre spośród języków interpretowanych są skryptowe, i to w jakiś sposób
zależy od interpretera języka
> > ?
> A nie zauważasz takiej prostej zasady że języki nazywane "skryptowymi"
> nie mają np kodu maszynowego i kod zawarty w skrypcie jest przetwarzany
> na bieżąco po uruchomieniu prosto z "pliku" gdzie zawarty jest skrypt?

Nie zauważam.
Zauważam, że języki skryptowe służą do pisania skryptów.
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.