W dniu 04.01.2020 o 00:55, g...@g...com pisze:
> W dniu sobota, 4 stycznia 2020 00:33:33 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
>
>>> Nie. To też nie.
>>> Kod źródłowy UNIXa możesz studiować z dala od jakiegokolwiek komputera. I on nie
jest skryptem, tylko złożonym systemem.
>>>
>> Kod napisany w czymkolwiek (moze być nawet Notatnik) bez przepuszczenia
>> go przez kompilator lub Interpreter jest co najwyżej kodem złożonego
>> systemu niczym więcej (Kupa znaków)
>
> Dokładnie.
> A po przepuszczeniu kodu przez kompilator zamienia się w kupę znaków będącą
wynikiem pracy kompilatora.
>
> Dopiero uruchomienie go spowoduje wygenerowanie procesu obliczeniowego.
>
>>> Cron nie jest skryptem.
>> Cron jest aplikacją (Interpretatorem) w postaci demona i to właśnie na
>> podstawie skryptu który mu się poda on działa
>
> Znów, interpreterem :)
>
Fakt :)
>>> 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."
> 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
- Brak kodu binarnego wynikającego bezpośrednio z twojego skryptu
>
> 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
>
>>>> Tak pokrótce o tym czy dany język jest skryptowy czy nie decyduję kilka
>>>> czynników: (skrócę do trzech bardzo ogólnych)
>>>> - sposób wykonania kodu
>>>
>>> Skąd ten pomysł?
>>
>> Interpreter języków skryptowych wykona kod który mu dostarczysz i to w
>> chwili wykonania programu. Ponadto kod języków skryptowych pozostaje
>> pisany tekstem bez zamiany na kod maszynowy
>
> 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?
>>>> - sposób dostarczenia kodu
>>>
>>> Czyli jak przekazuję kod źrodłowy programu w C, to język C staje się skryptowy?
>>>
>> Jaki przekaz masz konkretnie na myśli? Wynikiem wykonania kodu w C jest
>> plik binarny tyle i tylko tyle.
>>
>> Ten plik binarny żyje bez kodu. Jego kod jest zamieniony w postać
>> binarną i jest wykonywany zupełnie w inny sposób niż kod tzw języków
>> skryptowych odbywa się to w zupełnie innych warunkach
>
> 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.

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

Bardziej bym to nazwał "próbą" stworzenia języka skryptowego opartego na C.
>>>> - wyizolowanego środowiska uruchomieniowego uniezależnionego od
>>>> systemu/sprzętu
>>>
>>> Czyli C# jest skryptowy?
>>>
>> C# jest kompilowany do kodu pośredniego. Java podobnie a to sprawia że
>> wykonuje się w innych warunkach jak kod języka skryptowego i kompilatora
>> pliku binarnego
>>
>> Są pewne podobieństwa np wyizolowane środowiska uruchomieniowe ale
>> zasady działania są odmienne
>>
>>>>> Ponieważ zakres zastosowań Pythona pokrywa się z zakresem zastosowan Perla, a
niekiedy i języków powłoki, czasem i o nim mówi się, że jest "skryptowy".
>>>>
>>>> Błędne założenie ale już tu tyle napisałem że chyba da się zauważyć -
>>>> wspólną cechy dla języków skryptowych (interpretowanych) - zresztą to
>>>> jest do znalezienia w sieci. Wiki nie jest wyrocznią tutaj ale ma to
>>>> dość obrazowo przedstawione.
>>>>
>>>> https://pl.wikipedia.org/wiki/J%C4%99zyk_interpretow
any
>>>> https://pl.wikipedia.org/wiki/J%C4%99zyk_skryptowy
>>>
>>> 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.
>>>
>> Dokładnie tak ja to twierdze od samego początku
>
> 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]
>
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
>>> Zresztą Wikipedia potwierdza to, co napisałem:
>>>
>>> "Teoretycznie każdy język może być kompilowany i interpretowany, dlatego
rozróżnienie to polega na najczęściej stosowanych rozwiązaniach, a nie zależy od cech
samego języka"
>>>
>>> Zupełnie tak jak pisałem wcześniej! "Nie jest cechą języka!"
>>>
>> A to nie złapałeś że autorowi całego wątku nie chodzi i samą składnie
>> języka?
>>
>> Jemu chodzi przecież o to dlaczego Python nadaje się do "pewnych" rzeczy
>> a do innych nie
>
> Tematem naszej rozmowy jest to, co to znaczy "język skryptowy", a nie to, o co
chodzi autorowi całego wątku. W każdym razie ja się skupiłem wyłącznie na tej
kwestii.
>
>>> a w drugim artykule:
>>>
>>> "Języki skryptowe są to najczęściej języki interpretowane"
>>>
>>> Zwracam uwagę, że "najczęściej" nie oznacza "zawsze" ani "z konieczności".
>> A wiesz co to znaczy język jest interpretowany?
>>
>> Widzę po poniższej odpowiedzi ze skrypt według ciebie jest "sposobem
>> używania" niestety ale to nie jest tak
>>>
>>>>> Swego rodzaju "opozycją" do języków skryptowych są języki systemowe - czyli
takie, które służą do pisania dużych, skomplikowanych systemów (czy raczej: o których
się myśli, że do tego służą).
>>>>>
>>>> Dobrze że dodałeś nawias bo aż się chciało napisać co oznacza - tzw.
>>>> "języki systemowe" ale już mówisz o zastosowaniu języka a to zupełnie
>>>> inna para butów
>>>>> Ale to nie jest twardy podział. Języki takie jak PHP czy JavaScript można w tym
duchu nazwać "webowymi", bo się ich używa do opracowywania stron (choć nic nie stoi
na przeszkodzie, by pisać w nich skrypty).
>>>>>
>>>> Mówisz o sposobie zastosowania nie zmienia to faktu że są to języki
>>>> skryptowe
>>>
>>> Nie. "Skryptowość" nie jest cechą języka, tylko sposobu używania go.
>> Nie sposobem używania a sposobem wykonania się kodu tzw skryptu przez
>> zaimplementowany interpreter który go wykonuje.
>>
>> Nigdzie nie napisałem że jest to cecha języka jest to cecha
>> interpretatora danego języka.
>
> 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?

To tylko jedna z cech zresztą do znalezienia w internecie bez problemy
>
> Jeżeli tak, to jakie cechy musi spełniać ten interpreter, żeby interpretowany przez
niego język był skryptowy?
>

masz wyżej :)