🚀 go-pugleaf

"M.M." <m@g.c> Wrote in message:

>Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?
Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod
 warunkiem że nie przekracza  5tys linii, w tym do 100tys, a w
 jeszcze innym do milionów?

Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.
 10, może 30 programistów. Czyli trzeba mieć 10 programistów
 doskonale znających Pythona, trzymających jeden standard
 kodowania, zdyscyplinowanych i nie przeszkadzających sobie
 wzajemnie. Ok. Tyle że Python nie ma narzędzi zmuszających do
 zachowania porządku. Nie "pomagających" - ale właśnie
 zmuszających.

Czy na pewno nadal rozmawiamy o języku programowania czy już o
 bibliotekach? Pół miliona to 100 razy więcej niż 5tys. W C++ też
 pisze się efektywnie, ale trzeba mieć odpowiednie
 biblioteki.
W C++ też to można zrobić w 50 linijkach, kwestia bibliotek.

Owszem. Ale dla C++ nie ma PyPI - repozytorium ogólnie dostępnych
 bibliotek z sensowną licencją. Prosty przykład - w Pythonie jest
 matplotlib - a w C++ jest... No właśnie, nie ma czegoś
 takiego.

3. Siłą Pythona jest abstrakcja - patrz niżej:
def commute(a, b): return a*b - b*a

Dowcip w tym ze definicja commute jest zupełnie ogólna - mogą tam
 być zwkłe int, mogą być macierze, mogą być operatory różniczkowe.


Niby w C++ też, ale zapis jest z lekka rozwlekły:
template< class T >
void compute(T &a, T &b) { return a*b - b*a; }

Niezupełnie. Powinno być:

template<class Ta, class Tb, class T>
T compute(Ta a, Tb b) { return a*b - b*a; }

Ups, klasa T jest nieustalona

4. Python ma parę PASKUDNYCH wad.

a. Brak odporności na inżynierię odwrotną.
b. Brak sensownej wielowątkowości. Patrz GIL.
c. Ogromny rozmiar exe - dla hello world to około 30 mega.
d. Czasami 1000 wolniej działa niż to samo w C++.
e. Totalnie olane kwestie bezpieczeństwa.
f. Problematyczna implementacja niektórych operacji wbudowanych w
 sam język.

W dniu 03.01.2020 o 10:04, slawek pisze:
> "M.M." <m@g.c> Wrote in message:
> 
>> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?
> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod
>   warunkiem że nie przekracza  5tys linii, w tym do 100tys, a w
>   jeszcze innym do milionów?
> 
> Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.
>   10, może 30 programistów. 
Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych 
raczej ciężko wyliczyć ilość programistów.

Pytam z czystej ciekawości

Pozdrawiam

J-23 <Baczeklu@poczta.fm> Wrote in message:
> W dniu 03.01.2020 o 10:04, slawek pisze:> "M.M." <m@g.c> Wrote in message:> >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod>   warunkiem że nie przekracza  5tys linii, w tym do 100tys, a w>   jeszcze innym do milionów?> > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.>   10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów.Pytam z czystej ciekawościPozdrawiam


Na podstawie zebranego doświadczenia.

-- 

W dniu 04.01.2020 o 09:08, godek.maciek@gmail.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-bytecode
> 
> "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

> 

W dniu 04.01.2020 o 09:31, slawek pisze:
> J-23 <Baczeklu@poczta.fm> Wrote in message:
>> W dniu 03.01.2020 o 10:04, slawek pisze:> "M.M." <m@g.c> Wrote in message:> >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod>   warunkiem że nie przekracza  5tys linii, w tym do 100tys, a w>   jeszcze innym do milionów?> > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.>   10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów.Pytam z czystej ciekawościPozdrawiam
> 
> 
> Na podstawie zebranego doświadczenia.
> 
Chciałem ci coś innego napisać ale się powstrzymałem :)

ale 100 tys LOC kodu przy dziesięciu programistach to jakoś mizernie 
mało na jednego wychodzi - po 10 tys LOC stąd było pytanie o ramy 
czasowe bo jak są krótkie to wtedy rozumiem :)

Pozdrawiam
J-23

> >>> 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-bytecode
> > 
> > "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ą.

J-23 <Baczeklu@poczta.fm> Wrote in message:
> W dniu 04.01.2020 o 09:31, slawek pisze:> J-23 <Baczeklu@poczta.fm> Wrote in message:>> W dniu 03.01.2020 o 10:04, slawek pisze:> "M.M." <m@g.c> Wrote in message:> >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod>   warunkiem że nie przekracza  5tys linii, w tym do 100tys, a w>   jeszcze innym do milionów?> > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.>   10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów.Pytam z czystej ciekawościPozdrawiam> > > Na podstawie zebranego doświadczenia.> Chciałem ci coś innego napisać ale się powstrzymałem :)ale 100 tys LOC kodu przy dziesięciu programistach to jakoś mizernie mało na jednego wychodzi - po 10 tys LOC stąd było pytanie o ramy czasowe bo jak są krótkie to wtedy rozumiem :)PozdrawiamJ-23


Dwa - trzy miesiące. I drobiazg - kod, testy, dokumentacja itd.
 Przy założeniu że to nie będzie copy-paste, np takie:

A11 = cos(b11)
A12 = cos(b12)

To wychodzi jakoś tak 3000 linii na miesiąc, czyli około 200
 linijek dziennie (odlicz weekendy itp.), czyli 25 linijek na
 godzinę przy 8 godzinnym dniu pracy. Nie licząc komentarza,
 dokumentacji, jakichś papierków dla GUS (od 15 pracowników
 obowiązkowe). Odlicz czas na komunikację pomiędzy programistami,
 szkolenia, spotkania z tzw. klientem. Dolicz debugowanie. Z
 reguły co najmniej 50% kodu trzeba będzie pisać dwa razy - jakaś
 refaktoryzacja, zmiana priorytetów czy bibliotek. Chyba że
 nastawiamy się na klepanie bezkrytycznie wszystkiego jak leci...
 byle już nigdy do tego nie wracać. 

Moim zdaniem wykonalne, ale przy dobrej motywacji i kompetentnych
 pracownikach. Oczywiście może jesteś szybszy, ale większość ludzi
 jakich spotkałem, a którzy przechwalali się że "zrobią w
 weekend", nie potrafiło wytrzymać takiego tempa pracy jakie
 deklarowali.

Albo po prostu robili plagiaty i/lub w inny sposób korzystali z
 cudzej pracy.

Samo zrozumienie dziedziny problemu to mogą być tygodnie - np.
 gdybym pisał programy do obliczania podatków musiałbym zrozumieć
 prawo podatkowe danego kraju, może trochę karnego - a być może
 nawet nie jednego kraju, ale parunastu - na szczęście nie piszę
 programów księgowych itp.

Dlatego całkiem możliwe że tempo byłoby gorsze.

W dniu 04.01.2020 o 23:18, godek.maciek@gmail.com pisze:
>>>>> 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-bytecode
>>>
>>> "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.
No i co potem się z tym kodem dzieje ?
Po drugie oglądałeś plik .pyc? Każda instrukcja jest zamieniona na kod 
pośredni?
> 
>   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.

Moim zdaniem nie ze względu na przeznaczenie języki programowania są 
dzielone na skryptowe i kompilowane.

Czym jest skrypt a czym języki kompilowane i ty usiłujesz powiedzieć że 
skrypty to zestaw instrukcji wykonywanych jeden po drugim i to jest - 
prawda, ale ciężko ci pojąć dlaczego języki są tzw. językami skryptowymi.

Ty twierdzisz "bo ich przeznaczeniem jest pisanie skryptów"

Ustaliliśmy że skrypty są ciągiem instrukcji potwierdza to WIKIPEDIA

a jak nazwę naszą rozmowę skryptem to będzie błąd? Nie. A jak instrukcje 
obsługi gdzie mam napisane krok po kroku co mam wykonać - nazwę skryptem 
według definicji WIKIPEDII nazwę skryptem będzie błąd? Nie

bo przypominam z WIKIPEDII "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."

Jak widać z opisu programy napisane w językach skryptowych i co do tego 
co jest skryptem się zgadzamy nie zgadzamy się tylko co do definicji 
języka skryptowego. Ja jak mantrę powtarzam brak kodu binarnego i 
wyizolowane środowisko. Są to według mnie dwa najbardziej trafne ale nie 
jedyne. (Ograniczam się do dwóch by nie komplikować sprawy)

Teraz tak brak kodu binarnego to jest jasne i klarowne teraz postaram 
się wyjaśnić o co chodzi z tym środowiskiem odizolowanym bo tego nie 
rozumiesz jak widać po Twojej odpowiedzi. (W tekscie)
> 
> 
>>>> - 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.
Nie rozumiesz że kod bajtowy to nie to samo co plik binarny Może nie 
napisałem tego wprost ale myślałem że to jest oczywiście

To raczej ja mógłbym napisać dlaczego uważasz Pythona za kontrprzykład
> 
>>>>> 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.
> 
Srodowiskiem odizolowanym będzie wtedy kiedy dany "skrypt" czytaj zestaw 
instrukcji (nie myl z językami skryptowymi) działał po za systemem 
operacyjnym. Czyli przydzielaniem pamięci i innymi sprawami do wykonania 
"skryptu" zajmuje się tzw "Maszyna Wirtualna" i znowu tu nie pomyl np z 
niVirtualBoxem bo to inna para butów
> 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.
> 
A jesteś absolutnie pewny że zrobisz w nim to samo co w 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 ciekawe :) ale nie będę się czepiał zostawie to że to nie jest ciąg 
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.
> 
To że wikipedia tego nie napisała to nie znaczy że tak nie ma. Przykład 
odpad kod JS bez przeglądarki owszem są kompilatory o których pisaliśmy 
wcześniej ale masz przykład na Node.JS że ich kompilacja polega 
zwyczajnie na doklejeniu kodu uruchomieniowego do skryptu.
Który to jest odpalany we własnym środowisku uruchomieniowym

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

A znajdź cytat gdzie napisałem że to ma związek, nie ma. Języki 
kompilowane poprostu inaczej funkcjonują. Pokaż mi język uznawany za 
skryptowy obojętnie jak potraktowanny JIT który będzie miał dostęp do 
systemu bez swojego środowiska uruchomieniowego
> 
>> 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ą.
> 

No to czekam na to wyjaśnienie :)

W dniu niedziela, 5 stycznia 2020 02:45:25 UTC+1 użytkownik J-23 napisał:
> W dniu 04.01.2020 o 23:18, godek.maciek@gmail.com pisze:
> >>>>> 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-bytecode
> >>>
> >>> "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.
> No i co potem się z tym kodem dzieje ?
> Po drugie oglądałeś plik .pyc? Każda instrukcja jest zamieniona na kod 
> pośredni?
> > 
> >   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.
> 
> Moim zdaniem nie ze względu na przeznaczenie języki programowania są 
> dzielone na skryptowe i kompilowane.
> 
> Czym jest skrypt a czym języki kompilowane i ty usiłujesz powiedzieć że 
> skrypty to zestaw instrukcji wykonywanych jeden po drugim i to jest - 
> prawda, ale ciężko ci pojąć dlaczego języki są tzw. językami skryptowymi.
> 
> Ty twierdzisz "bo ich przeznaczeniem jest pisanie skryptów"
> 
> Ustaliliśmy że skrypty są ciągiem instrukcji potwierdza to WIKIPEDIA
> 
> a jak nazwę naszą rozmowę skryptem to będzie błąd? Nie. A jak instrukcje 
> obsługi gdzie mam napisane krok po kroku co mam wykonać - nazwę skryptem 
> według definicji WIKIPEDII nazwę skryptem będzie błąd? Nie
> 
> bo przypominam z WIKIPEDII "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."
> 
> Jak widać z opisu programy napisane w językach skryptowych i co do tego 
> co jest skryptem się zgadzamy nie zgadzamy się tylko co do definicji 
> języka skryptowego. Ja jak mantrę powtarzam brak kodu binarnego i 
> wyizolowane środowisko. Są to według mnie dwa najbardziej trafne ale nie 
> jedyne. (Ograniczam się do dwóch by nie komplikować sprawy)
> 
> Teraz tak brak kodu binarnego to jest jasne i klarowne teraz postaram 
> się wyjaśnić o co chodzi z tym środowiskiem odizolowanym bo tego nie 
> rozumiesz jak widać po Twojej odpowiedzi. (W tekscie)
> > 
> > 
> >>>> - 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.
> Nie rozumiesz że kod bajtowy to nie to samo co plik binarny Może nie 
> napisałem tego wprost ale myślałem że to jest oczywiście
> 
> To raczej ja mógłbym napisać dlaczego uważasz Pythona za kontrprzykład
> > 
> >>>>> 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.
> > 
> Srodowiskiem odizolowanym będzie wtedy kiedy dany "skrypt" czytaj zestaw 
> instrukcji (nie myl z językami skryptowymi) działał po za systemem 
> operacyjnym. Czyli przydzielaniem pamięci i innymi sprawami do wykonania 
> "skryptu" zajmuje się tzw "Maszyna Wirtualna" i znowu tu nie pomyl np z 
> niVirtualBoxem bo to inna para butów
> > 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.
> > 
> A jesteś absolutnie pewny że zrobisz w nim to samo co w 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 ciekawe :) ale nie będę się czepiał zostawie to że to nie jest ciąg 
> 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.
> > 
> To że wikipedia tego nie napisała to nie znaczy że tak nie ma. Przykład 
> odpad kod JS bez przeglądarki owszem są kompilatory o których pisaliśmy 
> wcześniej ale masz przykład na Node.JS że ich kompilacja polega 
> zwyczajnie na doklejeniu kodu uruchomieniowego do skryptu.
> Który to jest odpalany we własnym środowisku uruchomieniowym
> 
> >> 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ą".
> 
> A znajdź cytat gdzie napisałem że to ma związek, nie ma. Języki 
> kompilowane poprostu inaczej funkcjonują. Pokaż mi język uznawany za 
> skryptowy obojętnie jak potraktowanny JIT który będzie miał dostęp do 
> systemu bez swojego środowiska uruchomieniowego
> > 
> >> 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ą.
> > 
> 
> No to czekam na to wyjaśnienie :)

skrypty to kody tekstowe ktore zapodajesz do uruchomienia

jesli ten sam kod zapodasz do transformacji na cos po czym odpalasz to drugie to uwaga skupia sie na tym drugim 
i juz nie mowi sie o skryptach


dlatego moim zdaniem nawet kod w asmie moze byc skryptem, jesli poprostu zapodasz go do uruchomienia, z kolei jesliby odebrac typowym skryptom mozliwosc "uruchamiania ich" jako cos niezaleznego zdolnego do uruchomienia to przestalybybyc skryptami (ale z tym chyab trudniej)

J-23 <Baczeklu@poczta.fm> Wrote:

> z WIKIPEDII "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."


Wikipedia jako najwyższy Autorytet? Przeedytować hasło w Wikipedii
 można w pięć minut, każdy to może zrobić.

Problem z definicją "języka skryptowego" w Wikipedii jest taki, że
 język skryptowy jest zdefiniowany przez skrypt a parę linijek
 dalej skrypt jest zdefiniowany przez język skryptowy.  Czyli
 odwołanie cykliczne, inaczej błędne koło, patrz też
 https://pl.m.wikipedia.org/wiki/B%C5%82%C4%99dne_ko%C5%82o_w_defi
niowaniu

Sensowne natomiast byłaby definicja: języków skryptowych jako
 takich w których program jest rozpowszechniany zasadniczo w
 postaci kodu źródłowego lub kontenerów (dających się rozpakować)
 z takowym; co skutkuje brakiem możliwości uniemożliwienia
 użytkownikowi końcowemu dysponującemu programem łatwego
 wprowadzania modyfikacji (w tym ad hoc) do programu.

Problemy... Obsfukacja? Kompilatory "interpretowanych" języków -
 np. QuickBasic?! PHP - to ratuje "dysponującym" - end userem jest
 webmaster. Zasoby takie jak obrazki, muzyka - to też kod
 źródłowy. Ale co z embeded?!

Naturalnie i kompilat można zhackować. Ale nie jest to "łatwe".

Jest jeszcze drugie znaczenie "języków skryptowych": pogardliwe
 określenie języków w których pisanie programów jest nisko
 wynagradzane pod pozorem braku konieczności posiadania wysokich
 kwalifikacji przez programistów, nie przeznaczonych do tworzenia
 dużych i odpowiedzialnych programów.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On Saturday, January 4, 2020 at 10:18:10 PM UTC+1, J-23 wrote:
> W dniu 04.01.2020 o 09:31, slawek pisze:
> > J-23 <B@p.f> Wrote in message:
> >> W dniu 03.01.2020 o 10:04, slawek pisze:> "M.M." <m@g.c> Wrote in message:> >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod>   warunkiem że nie przekracza  5tys linii, w tym do 100tys, a w>   jeszcze innym do milionów?> > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.>   10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów.Pytam z czystej ciekawościPozdrawiam
> > 
> > 
> > Na podstawie zebranego doświadczenia.
> > 
> Chciałem ci coś innego napisać ale się powstrzymałem :)
> 
> ale 100 tys LOC kodu przy dziesięciu programistach to jakoś mizernie 
> mało na jednego wychodzi - po 10 tys LOC stąd było pytanie o ramy 
> czasowe bo jak są krótkie to wtedy rozumiem :)

Zależy jak trudny problem.

Pozdrawiam

On Saturday, January 4, 2020 at 11:48:40 PM UTC+1, slawek wrote:
> J-23 <B@p.f> Wrote in message:
> > W dniu 04.01.2020 o 09:31, slawek pisze:> J-23 <B@p.f> Wrote in message:>> W dniu 03.01.2020 o 10:04, slawek pisze:> "M.M." <m@g.c> Wrote in message:> >> Często czytałem że większe programy pisane w językach z dynamicznym typowaniem szybko stają się trudne w zarządzaniu, nawet powtarzałem tę opinię. Ale nie wiem ile w tym prawdy. Jakie jest uzasadnienie?> Dlaczego w tym języku można efektywnie tworzyć oprogramowanie pod>   warunkiem że nie przekracza  5tys linii, w tym do 100tys, a w>   jeszcze innym do milionów?> > Ja szacuję to tak, że 100 tysięcy LOC to jest to robota dla np.>   10, może 30 programistów. Jaki czas zakładasz na napisanie tej ilości kodu? Bo bez ram czasowych raczej ciężko wyliczyć ilość programistów.Pytam z czystej ciekawościPozdrawiam> > > Na podstawie zebranego doświadczenia.> Chciałem ci coś innego napisać ale się powstrzymałem :)ale 100 tys LOC kodu przy dziesięciu programistach to jakoś mizernie mało na jednego wychodzi - po 10 tys LOC stąd było pytanie o ramy czasowe bo jak są krótkie to wtedy rozumiem :)PozdrawiamJ-23
> 
> 
> Dwa - trzy miesiące. I drobiazg - kod, testy, dokumentacja itd.
>  Przy założeniu że to nie będzie copy-paste, np takie:
> 
> A11 = cos(b11)
> A12 = cos(b12)
> 
> To wychodzi jakoś tak 3000 linii na miesiąc, czyli około 200
>  linijek dziennie (odlicz weekendy itp.), czyli 25 linijek na
>  godzinę przy 8 godzinnym dniu pracy. Nie licząc komentarza,
>  dokumentacji, jakichś papierków dla GUS (od 15 pracowników
>  obowiązkowe). Odlicz czas na komunikację pomiędzy programistami,
>  szkolenia, spotkania z tzw. klientem. Dolicz debugowanie. Z
>  reguły co najmniej 50% kodu trzeba będzie pisać dwa razy - jakaś
>  refaktoryzacja, zmiana priorytetów czy bibliotek. Chyba że
>  nastawiamy się na klepanie bezkrytycznie wszystkiego jak leci...
>  byle już nigdy do tego nie wracać. 
> 
> Moim zdaniem wykonalne, ale przy dobrej motywacji i kompetentnych
>  pracownikach. Oczywiście może jesteś szybszy, ale większość ludzi
>  jakich spotkałem, a którzy przechwalali się że "zrobią w
>  weekend", nie potrafiło wytrzymać takiego tempa pracy jakie
>  deklarowali.
> 
> Albo po prostu robili plagiaty i/lub w inny sposób korzystali z
>  cudzej pracy.
> 
> Samo zrozumienie dziedziny problemu to mogą być tygodnie - np.
>  gdybym pisał programy do obliczania podatków musiałbym zrozumieć
>  prawo podatkowe danego kraju, może trochę karnego - a być może
>  nawet nie jednego kraju, ale parunastu - na szczęście nie piszę
>  programów księgowych itp.
> 
> Dlatego całkiem możliwe że tempo byłoby gorsze.

Zgadzam się w całości, nawet dodałbym, że może być znaaaaacznie gorsze, gdy 
właśnie uwzględnić zrozumienie problemu, optymalizację, testy, przenośność
kodu, wersje, refaktoryzację, dynamicznie zmieniające się wymagania klienta....
Ktoś kiedyś pisał, że z uwzględnieniem wersji wychodzą 2 linijki kodu na
dobę na programistę. Jeśli zadanie proste, dobrze znane, jeśli projekt mały, 
to i można 2tys linijek na dobę wklepać z czego 90% interfejs w htmlu.
Mi czasami przez tydzień pracy dzień w dzień ubywa linijek kodu, a nawet
całych plików, bo po okresie wstępnego-szalonego prototypu wydzielam 
procedury do wspólnych obliczeń.


Pozdrawiam

W dniu 05.01.2020 o 09:39, fir pisze:
>>
>> No to czekam na to wyjaśnienie :)
> 
> skrypty to kody tekstowe ktore zapodajesz do uruchomienia
> 
> jesli ten sam kod zapodasz do transformacji na cos po czym odpalasz to drugie to uwaga skupia sie na tym drugim
> i juz nie mowi sie o skryptach
> 
> 
> dlatego moim zdaniem nawet kod w asmie moze byc skryptem, jesli poprostu zapodasz go do uruchomienia, z kolei jesliby odebrac typowym skryptom mozliwosc "uruchamiania ich" jako cos niezaleznego zdolnego do uruchomienia to przestalybybyc skryptami (ale z tym chyab trudniej)
> 
Nie chodzi o definicje: co jest "skryptem" ,bo to wiemy i rozumiemy a 
chodzi o to "czemu język programowania jest nazywany językiem 
skryptowym". Ja naprawdę mam ubaw jak słyszę cytuję "C# i Java nie są 
"językami skryptowymi", bo ich przeznaczeniem nie jest pisanie 
skryptów." lub "bo ich przeznaczeniem jest pisanie skryptów" Nawet 
pozwoliłem sobie na małą prowokację pisząc: "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" w odpowiedzi dostałem owszem linka gdzie piszę że Python jest 
kompilowany do kodu bajtowego ale nadal nie dostałem odpowiedzi dlaczego 
jest podział na "języki skryptowe" i kompilowane. Dostawałem odpowiedzi 
że nie ma znaczenia jaki to język bo są narzędzia zwane cytuje 
"JIT-kompilatory, które generują kod maszynowy. " no i to byłoby prawdą 
gdyby nie zestawiał ktoś tego na równi z językami kompilowanymi tj. C, 
C++ czy Pascal i działa to tak samo jak języki kompilowane. Otóż nie 
działa co najwyżej działa w podobny sposób jak Wirtualna Maszyna Javy.

Pozdrawiam
J-23

W dniu niedziela, 5 stycznia 2020 23:17:04 UTC+1 użytkownik J-23 napisał:
> W dniu 05.01.2020 o 09:39, fir pisze:
> >>
> >> No to czekam na to wyjaśnienie :)
> > 
> > skrypty to kody tekstowe ktore zapodajesz do uruchomienia
> > 
> > jesli ten sam kod zapodasz do transformacji na cos po czym odpalasz to drugie to uwaga skupia sie na tym drugim
> > i juz nie mowi sie o skryptach
> > 
> > 
> > dlatego moim zdaniem nawet kod w asmie moze byc skryptem, jesli poprostu zapodasz go do uruchomienia, z kolei jesliby odebrac typowym skryptom mozliwosc "uruchamiania ich" jako cos niezaleznego zdolnego do uruchomienia to przestalybybyc skryptami (ale z tym chyab trudniej)
> > 
> Nie chodzi o definicje: co jest "skryptem" ,bo to wiemy i rozumiemy a 
> chodzi o to "czemu język programowania jest nazywany językiem 
> skryptowym". Ja naprawdę mam ubaw jak słyszę cytuję "C# i Java nie są 
> "językami skryptowymi", bo ich przeznaczeniem nie jest pisanie 
> skryptów." lub "bo ich przeznaczeniem jest pisanie skryptów"

Cieszę się, że masz ubaw. To ważne, żeby mieć w życiu ubaw.

W takim razie zmieńmy trochę przedmiot badań.

Co sprawia, że niektóre samochody nazywane są "sportowymi"?

> Nawet 
> pozwoliłem sobie na małą prowokację pisząc: "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" w odpowiedzi dostałem owszem linka gdzie piszę że Python jest 
> kompilowany do kodu bajtowego ale nadal nie dostałem odpowiedzi dlaczego 
> jest podział na "języki skryptowe" i kompilowane.

Nie ma podziału na "języki skryptowe i kompilowane".
Tak jak nie ma podziału na "przedmioty okrągłe i różowe".

To nie jest podział. To są odrębne kategorie.
(Nawet jeżeli akurat tak się zdarzyło, większość różowych przedmiotów jest okrągła)

Podział byłby na przykład na "przedmioty trójkątne, czterokątne, pięciokątne i pozostałe". Albo na "okrągłe i nie-okrągłe".

W dniu niedziela, 5 stycznia 2020 02:45:25 UTC+1 użytkownik J-23 napisał:

> Moim zdaniem nie ze względu na przeznaczenie języki programowania są 
> dzielone na skryptowe i kompilowane.
> 
> Czym jest skrypt a czym języki kompilowane i ty usiłujesz powiedzieć że 
> skrypty to zestaw instrukcji wykonywanych jeden po drugim i to jest - 
> prawda, ale ciężko ci pojąć dlaczego języki są tzw. językami skryptowymi.
> 
> Ty twierdzisz "bo ich przeznaczeniem jest pisanie skryptów"
> 
> Ustaliliśmy że skrypty są ciągiem instrukcji potwierdza to WIKIPEDIA
> 
> a jak nazwę naszą rozmowę skryptem to będzie błąd? Nie.

Tak. Nasza rozmowa to wymiana opinii, a nie ciąg instrukcji do wykonania.
(ewentualnie można ją nazwać "logiem")

> A jak instrukcje 
> obsługi gdzie mam napisane krok po kroku co mam wykonać - nazwę skryptem 
> według definicji WIKIPEDII nazwę skryptem będzie błąd? Nie
> 
> bo przypominam z WIKIPEDII "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."
> 
> Jak widać z opisu programy napisane w językach skryptowych i co do tego 
> co jest skryptem się zgadzamy nie zgadzamy się tylko co do definicji 
> języka skryptowego. Ja jak mantrę powtarzam brak kodu binarnego i 
> wyizolowane środowisko. Są to według mnie dwa najbardziej trafne ale nie 
> jedyne. (Ograniczam się do dwóch by nie komplikować sprawy)

Dokładnie tak. Według Ciebie.
Miałem w liceum kolegę, który na określenie precedensu użył słowa "ewenement".
Jednak nie zmieniło to znaczenia słowa "ewenement". Po prostu błędnie użył słowa.

> > 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.
> > 
> Srodowiskiem odizolowanym będzie wtedy kiedy dany "skrypt" czytaj zestaw 
> instrukcji (nie myl z językami skryptowymi) działał po za systemem 
> operacyjnym. Czyli przydzielaniem pamięci i innymi sprawami do wykonania 
> "skryptu" zajmuje się tzw "Maszyna Wirtualna" i znowu tu nie pomyl np z 
> niVirtualBoxem bo to inna para butów

To bez różnicy.
I to wiadomo już od 1935 roku.
Możesz sobie zbudować fizyczną maszynę realizującą API JVM.
Możesz też na JVM odpalić interpreter kodu maszynowego.
Program z założenia nie może wiedzieć "w czym działa".
Tworcy gier na Nintendo myśleli, że robią gry na Nintendo, a ja je sobie teraz chamsko odpalam w emulatorze na moim telefonie.

> > 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.
> > 
> A jesteś absolutnie pewny że zrobisz w nim to samo co w C?

Jeżeli ma w 100% kompatybilną semantykę, to tak.

> >>> 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 ciekawe :) ale nie będę się czepiał zostawie to że to nie jest ciąg 
> 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.
> > 
> To że wikipedia tego nie napisała to nie znaczy że tak nie ma.

Tzn. po prostu coś sobie twierdzisz.

> >> 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ą".
> 
> A znajdź cytat gdzie napisałem że to ma związek, nie ma. Języki 
> kompilowane poprostu inaczej funkcjonują. Pokaż mi język uznawany za 
> skryptowy obojętnie jak potraktowanny JIT który będzie miał dostęp do 
> systemu bez swojego środowiska uruchomieniowego

Pokaż mi jakikolwiek język który będzie miał dostęp do systemu bez swojego środowiska uruchomieniowego.

> >> 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ą.
> > 
> 
> No to czekam na to wyjaśnienie :)

Język skryptowy to język, którego przeznaczeniem jest pisanie skryptów
(czyli czegoś, co automatyzuje interakcje użytkownika z systemem)
Można w nim pisać duże, złożone programy, ale to raczej mija się z celem.
C# i Java to języki, których przeznaczeniem jest tworzenie aplikacji.
Są pod tym kątem zoptymalizowane. I tyle. Nie ma żadnej tajemnicy.

W dniu 06.01.2020 o 00:30, godek.maciek@gmail.com pisze:
> W dniu niedziela, 5 stycznia 2020 23:17:04 UTC+1 użytkownik J-23 napisał:
>> W dniu 05.01.2020 o 09:39, fir pisze:
>>>>
>>>> No to czekam na to wyjaśnienie :)
>>>
>>> skrypty to kody tekstowe ktore zapodajesz do uruchomienia
>>>
>>> jesli ten sam kod zapodasz do transformacji na cos po czym odpalasz to drugie to uwaga skupia sie na tym drugim
>>> i juz nie mowi sie o skryptach
>>>
>>>
>>> dlatego moim zdaniem nawet kod w asmie moze byc skryptem, jesli poprostu zapodasz go do uruchomienia, z kolei jesliby odebrac typowym skryptom mozliwosc "uruchamiania ich" jako cos niezaleznego zdolnego do uruchomienia to przestalybybyc skryptami (ale z tym chyab trudniej)
>>>
>> Nie chodzi o definicje: co jest "skryptem" ,bo to wiemy i rozumiemy a
>> chodzi o to "czemu język programowania jest nazywany językiem
>> skryptowym". Ja naprawdę mam ubaw jak słyszę cytuję "C# i Java nie są
>> "językami skryptowymi", bo ich przeznaczeniem nie jest pisanie
>> skryptów." lub "bo ich przeznaczeniem jest pisanie skryptów"
> 
> Cieszę się, że masz ubaw. To ważne, żeby mieć w życiu ubaw.
Bez "spiny" :) Tak naprawdę każdy język może być nazwany skryptowym 
nawet Java oto potwierdzenie tego co piszę 
https://pl.wikipedia.org/wiki/J%C4%99zyk_kompilowany dlatego napisałem w 
jednym z postów "Java czy .NET można uznać
za skryptowe odpowiem po raz kolejny - nie - a wynika to z różnic ich
implementacji." O ile mnie pamięć nie myli nawet byl o to spór w sądzie 
który wytoczyła firma (nie pamiętam jej nazwy) ale jeszcze firmie SAN o 
to czy Java jest językiem kompilowanym - chodziło o jakiś zastosowany 
patent ale dokładnie tego nie przytoczę. Koniec końców SAN wygrał 
udowadniając że defakto jest językiem skryptowym przytaczając podobny 
tekst do tego z WIKIPEDII (chodzi oczywiście o sens)

Moim zdaniem (ale to już raczej dowolna interpretacja nie każdy się musi 
z nią zgodzić) jeżeli już mówimy o językach tzw "skryptowych" to głowną 
cechą jest to że działają w "odizolowanym środowisk"

Jednego przyznaje dowiedziałem się podczas wymiany Postów tutaj że 
Python jako język nie jest określany teraz jako skryptowy czy 
kompilowany tylko wieloparadygmatowy

> 
> W takim razie zmieńmy trochę przedmiot badań.
> 
> Co sprawia, że niektóre samochody nazywane są "sportowymi"?
Tak w jednym zdaniu:)? Decydują o tym ich właściwości których nie 
spotkamy w samochodach które w większości znajdują się na drogach:)
> 
>> Nawet
>> pozwoliłem sobie na małą prowokację pisząc: "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" w odpowiedzi dostałem owszem linka gdzie piszę że Python jest
>> kompilowany do kodu bajtowego ale nadal nie dostałem odpowiedzi dlaczego
>> jest podział na "języki skryptowe" i kompilowane.
> 
> Nie ma podziału na "języki skryptowe i kompilowane".
> Tak jak nie ma podziału na "przedmioty okrągłe i różowe".
> 
> To nie jest podział. To są odrębne kategorie.
> (Nawet jeżeli akurat tak się zdarzyło, większość różowych przedmiotów jest okrągła)
Słowo podział jest "Synonimem" do słowa kategoria - więc nie ma różnicy 
czy nazwiesz to podział czy kategoria to jedno i to samo
https://www.synonimy.pl/synonim/podzia%C5%82/
> 
> Podział byłby na przykład na "przedmioty trójkątne, czterokątne, pięciokątne i pozostałe". Albo na "okrągłe i nie-okrągłe".
> 

Tak czy siak dzięki za dyskusje z zachowaniem "Pewnego Poziomu" ,który 
udało Ci się zachować. Mam nadzieje że jeszcze będzie okazja kiedyś po 
dyskutować.

Pozdrawiam
J-23

W dniu poniedziałek, 6 stycznia 2020 01:40:35 UTC+1 użytkownik J-23 napisał:

> > Cieszę się, że masz ubaw. To ważne, żeby mieć w życiu ubaw.
> Bez "spiny" :)

Nie ma spiny, serio.
Naprawdę ważne, żeby mieć w życiu ubaw :)

> Tak naprawdę każdy język może być nazwany skryptowym 
> nawet Java oto potwierdzenie tego co piszę 
> https://pl.wikipedia.org/wiki/J%C4%99zyk_kompilowany

W artykule się ani razu nie pojawia słowo "skryptowy".

> dlatego napisałem w 
> jednym z postów "Java czy .NET można uznać
> za skryptowe odpowiem po raz kolejny - nie - a wynika to z różnic ich
> implementacji." O ile mnie pamięć nie myli nawet byl o to spór w sądzie 
> który wytoczyła firma (nie pamiętam jej nazwy) ale jeszcze firmie SAN o 
> to czy Java jest językiem kompilowanym - chodziło o jakiś zastosowany 
> patent ale dokładnie tego nie przytoczę.

Raczej się firma nazywała Sun Microsystems.

> Moim zdaniem (ale to już raczej dowolna interpretacja nie każdy się musi 
> z nią zgodzić) jeżeli już mówimy o językach tzw "skryptowych" to głowną 
> cechą jest to że działają w "odizolowanym środowisk"

Główną cechą jest to, że służą do pisania skryptów.
I to nie wynika z czyjegoś zdania, tylko z tego, jak funkcjonuje język.
(I jasne, że świnka morska nie jest morska i nie jest świnką, ale
po co te sprawy jeszcze bardziej komplikować?)

> Jednego przyznaje dowiedziałem się podczas wymiany Postów tutaj że 
> Python jako język nie jest określany teraz jako skryptowy czy 
> kompilowany tylko wieloparadygmatowy

To tak jakby powiedzieć, że Michael Jordan nie jest określany jako "wysoki", tylko "ciemnoskóry".
C++ też jest wieloparadygmatowy, ale jest kompilowany.
To są ortogonalne cechy.

Python może jest "mniej skryptowy" niż kiedyś z tego względu, że mniej się o nim myśli jako o języku do pisania skryptów, a bardziej - jak o języku ogólnego przeznaczenia.

> > 
> > W takim razie zmieńmy trochę przedmiot badań.
> > 
> > Co sprawia, że niektóre samochody nazywane są "sportowymi"?
> Tak w jednym zdaniu:)? Decydują o tym ich właściwości których nie 
> spotkamy w samochodach które w większości znajdują się na drogach:)
> > 
> >> Nawet
> >> pozwoliłem sobie na małą prowokację pisząc: "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" w odpowiedzi dostałem owszem linka gdzie piszę że Python jest
> >> kompilowany do kodu bajtowego ale nadal nie dostałem odpowiedzi dlaczego
> >> jest podział na "języki skryptowe" i kompilowane.
> > 
> > Nie ma podziału na "języki skryptowe i kompilowane".
> > Tak jak nie ma podziału na "przedmioty okrągłe i różowe".
> > 
> > To nie jest podział. To są odrębne kategorie.
> > (Nawet jeżeli akurat tak się zdarzyło, większość różowych przedmiotów jest okrągła)
> Słowo podział jest "Synonimem" do słowa kategoria - więc nie ma różnicy 
> czy nazwiesz to podział czy kategoria to jedno i to samo

Jasne. Ale nie o to mi chodzi.
Możesz sobie podzielić przedmioty np. według kolorów. I wtedy kategorią jest "kolor". Dlatego moglibyśmy powiedzieć, że np. są przedmioty zielone, niebieskie, pomarańczowe itd.
Inną kategorią mógłby być kształt: przedmioty trójkątne, okrągłe, kwadratowe itp.
I oczywiście przedmiot trójkątny nie jest kwadratowy, przedmiot zielony nie jest niebieski itd. Wtedy mamy do czynienia z podziałem.

Natomiast "podział" na przedmioty różowe i okrągłe nie jest podziałem, bo mogą istnieć przedmioty okrągłe i różowe.
Tak jak podziałem nie jest "podział" na języki skryptowe i kompilowane.
"Skryptowe" znaczy tyle co "przeznaczone do pisania skryptów".
"Kompilowane" to "takie, które przed uruchomieniem wymagają translacji do kodu niskopoziomowego".

Nie ma sprzeczności w powiedzeniu, że dany język służy do pisania skryptów i wymaga przed uruchomieniem translacji do kodu niskopoziomowego (nawet jeśli taka sytuacja jest rzadko spotykana, albo nie jest spotykana w ogóle)

> > Podział byłby na przykład na "przedmioty trójkątne, czterokątne, pięciokątne i pozostałe". Albo na "okrągłe i nie-okrągłe".
> > 
> 
> Tak czy siak dzięki za dyskusje z zachowaniem "Pewnego Poziomu" ,który 
> udało Ci się zachować. Mam nadzieje że jeszcze będzie okazja kiedyś po 
> dyskutować.

Ja również dziękuję. Oby jak najwięcej merytorycznych argumentów, a jak najmniej wzajemnego się obrażania i "patrzenia na innych z góry" (co kiedyś chyba było tu standardem)

W dniu niedziela, 5 stycznia 2020 10:25:35 UTC+1 użytkownik slawek napisał:
> 
> > z WIKIPEDII "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."
> 
> 
> Wikipedia jako najwyższy Autorytet? Przeedytować hasło w Wikipedii
>  można w pięć minut, każdy to może zrobić.

Tak, nawet licealista bez matury.
Ale jak napiszesz jakąś głupotę, to Wojownicy Wikipedii się z nią jeszcze szybciej rozprawią.

Zaś Wikipedia może nie jest "najwyższym autorytetem", ale jest dobrą instancją, jeżeli idzie o konsensus w kwestii rozumienia słów.

> Problem z definicją "języka skryptowego" w Wikipedii jest taki, że
>  język skryptowy jest zdefiniowany przez skrypt a parę linijek
>  dalej skrypt jest zdefiniowany przez język skryptowy.  Czyli
>  odwołanie cykliczne, inaczej błędne koło,

Nie ma tutaj problemu odwołania cyklicznego.
(I w definicjach rekurencyjnych albo ko-rekurencyjnych też nie ma)

Zamień sobie problematyczną dla Ciebie frazę

"programy napisane w językach skryptowych"

na

"programy napisane w specjalnie przeznaczonych do tego celu językach"

i po sprawie.