-
Data: 2020-01-04 00:32:43
Temat: Re: Czemu Python jest jaki jest?
Od: J-23 <B...@p...fm> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]W dniu 03.01.2020 o 21:27, g...@g...com pisze:
> W dniu piątek, 3 stycznia 2020 20:48:15 UTC+1 użytkownik J-23 napisał:
>
>>> A do których języków nie potrzeba środowiska uruchomieniowego?
>> Chyba inaczej rozumiemy środowiska uruchomieniowe.
>
> Ja rozumiem dosłownie. Jako kontekst, w którym program jest wykonywany, oraz
zasoby, które ma do dyspozycji w momencie działania.
I to jest tylko połowa prawdy. Druga połowa jet taka że programy
odpalane w tzw. środowiskach uruchomieniowych nie mają dostępu np do
sprzętu wszystko odbywa się w izolowanym środowisku zwanym właśnie
środowiskiem uruchomieniowym
>
>> 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)
>>> Kiedyś mówiło się o "językach kompilowanych i interpretowanych".
>>> Ale to, czy dany język jest "kompilowany czy interpretowany", nie jest kwestia
samego języka, tylko narzędzi. (Np. istnieją interpretery języka C)
>>
>> Jeżeli bierzesz sam kod pod uwagę "bez próby jego wykonania" To owszem
>> masz 100% racji i nawet wtedy pokuszę się o powiedzenie ze 100% kodu -
>> niezależnie w jakim języku jest napisane będzie niczym więcej jak tylko
>> "skryptem"
>
> 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)
>> Ale jeżeli o tym rozmawiamy to nie ma sensu też wtrącać różnic między
>> językami typu szybkość wykonania czy wydajność pod względem np użycia
>> ilości pamięci
>
> No bo nie ma sensu.
> Ma sens mówić o różnicach w wydajności pomiędzy implementacjami różnych języków.
>
> Kiedy mówi się, że C jest szybsze od Pythona, ma się na myśli, że powszechnie
dostępne implementacje C są szybsze od powszechnie dostępnych implementacji Pythona.
>
Tutaj pełna zgoda
>>> Określenie "język skryptowy" nie ma związku z tym, jaka jest technika
implementacji. Z definicji jest to "język służący do pisania skryptów"
>>> (albo - bardziej pedantycznie: język, o którym myśli się jako o języku, w którym
pisze się skrypty).
>> Mylisz trochę pojęcia tzn. masz racje ale mylisz skrypt który wykonuje
>> pewne zadania np w systemie jak np. cron który ma za zadanie
>> w "uproszczeniu" uruchomić określone programy by wykonać określone zadanie
>
> 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
Jest
> <grzmoty i pioruny>
> demonem.
>
>>> I znów, to, czy język służy, czy nie służy do pisania skryptów, nie jest cechą
samego języka, tylko tego, w jaki sposób ktoś postanowi go użyć.
>>
>> I znowu mówisz o języku jak o "suchym tekście" który można by zapisać na
>> kartce papieru i zamknąć w zeszycie.
>
> 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
>
>>>
>>> Prototypowe języki skryptowe to języki powłoki (np. bash albo DOSowe batche albo
skrypty w PowerShellu).
>> To prawda ale z jedną uwagą bash czy PowerShell są interpretatorami tego
>> co zostanie im dostarczone w postaci skryptu i to co napisałeś poniżej
>> ma sens tylko "połowicznie"
Ogólnie zasada działania jest ta sama jak w cron czyli działa na
podstawie dostarczonego skryptu (Kodu) inaczej nie działa
>
> Nie rozumiem.
> (Ale - gwoli ścisłości - interpreterami. Interpretator to osoba.)
Zgadza się mój błąd rozpędziłem się :)
>
>>> Są one "skryptowe", bo pełnią funkcję "end-user programmingu" - tzn. ich autorzy
nie muszą rozumieć szczegółów implementacji systemów, a wystarczy, że znają zasady
korzystania z tych systemów.
>>>
>>
>> "Połowicznie" jest to prawda. Bo o ile do napisania "skryptu" nie jest
>> potrzebna wiedza o implementacji jakiegoś elementu systemu. To nie to
>> decyduje o "skryptowości" danego języka.
>>
>> 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
>
>> - 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
>> - 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
> 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
> 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.
> To nie one są "skryptowe", tylko my, używając tej nazwy, przemycamy informację o
tym, w jaki sposób zazwyczaj z nich korzystamy.
> Podobnie gdy mówimy np. że jakaś dziewczyna jest piękna, to tak naprawdę nic nie
mówimy o tej dziewczynie, tylko o naszych gustach. Albo gdy mówimy, że jakiś czyn
jest haniebny, to nie mówimy o tym czynie, tylko o naszym systemie wartości.
>
>>> No, a PostScript jest oczywiście stosowy.
>>
>> Szczerze powiem:) nie wiem nigdy nie miałem potrzeby tego używać :)
>
> Pewnie używałeś nawet o tym nie wiedząc, np. otwierając dokument PDF.
>
Tak ale nigdy bezpośrednio nic nie skrobałem w PostScript
Pozdrawiam
Następne wpisy z tego wątku
- 04.01.20 00:55 g...@g...com
- 04.01.20 01:23 g...@g...com
- 04.01.20 02:32 J-23
- 04.01.20 09:08 g...@g...com
- 04.01.20 09:50 g...@g...com
- 04.01.20 11:13 g...@g...com
- 04.01.20 13:39 fir
- 04.01.20 15:48 g...@g...com
- 04.01.20 16:09 fir
- 04.01.20 19:33 M.M.
- 04.01.20 22:03 J-23
- 04.01.20 22:18 J-23
- 04.01.20 23:18 g...@g...com
- 05.01.20 02:45 J-23
- 05.01.20 09:39 fir
Najnowsze wątki z tej grupy
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
Najnowsze wątki
- 2024-11-08 Warszawa => Head of International Freight Forwarding Department <=
- 2024-11-08 Warszawa => Key Account Manager <=
- 2024-11-08 Szczecin => Key Account Manager (ERP) <=
- 2024-11-08 Białystok => Full Stack web developer (obszar .Net Core, Angular6+) <
- 2024-11-08 Wrocław => Senior PHP Symfony Developer <=
- 2024-11-08 Warszawa => QA Engineer <=
- 2024-11-08 Warszawa => QA Inżynier <=
- 2024-11-08 Warszawa => Key Account Manager <=
- 2024-11-08 Gdańsk => Software .Net Developer <=
- 2024-11-08 Akumulator Hyundai
- 2024-11-08 Warszawa => Manager/Specialist e-commerce (B2C) <=
- 2024-11-08 Gdańsk => Specjalista ds. Sprzedaży <=
- 2024-11-08 Gdańsk => Kierownik Działu Spedycji Międzynarodowej <=
- 2024-11-08 znaj podstawe
- 2024-11-08 Chrzanów => Specjalista ds. public relations <=