W dniu 04.01.2020 o 09:08, g...@g...com pisze:
> 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"

A przeczytałeś całość, zakładam że nie bo byś wiedział że kod pośredni
jest tworzony tylko niektórych funkcji. 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."

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

Jeżeli masz na myśli takie coś jak VirtualBox lub soft innych
producentów to owszem izolujesz od sprzętu fizycznego ale nie to zależy
od implementacji tej maszyny

Są maszyny wirtualne które działają na takim dostępie jak zwykły PC

Ale to raczej mały ma związek z maszynami Wirtualnymi zaszytymi w
językach programowania

>
>> - 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
>
>>> 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ć.
>
Tak i nie musisz się martwić podczas pisania czy softu czy ci to co
chcesz obsłuży? Bądź poważny :)
>>> 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
>
>>> 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?
>
No to i tak dla mnie pozostanie to próbą stworzenia najprawdopodobniej
języka skryptowego bazującego na C

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

To ja zadam pytanie teraz co według ciebie jest skryptem/a co zwykłym
tekstem napisanym.
> 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

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.

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.

Pozdrawiam
J-23

>