🚀 go-pugleaf

Julia

On Friday, December 20, 2019 at 7:39:45 AM UTC+1, godek...@gmail.com wrote:
> Julia

Hmmmm

On Friday, December 20, 2019 at 7:39:45 AM UTC+1, godek...@gmail.com wrote:
> Julia

Pierwszy link z googla trafia do forum:

https://4programmers.net/Forum/Inne/311782-julia_jezyk_do_obliczen_naukowych

Prawdę powiadają tam?

Pozdrawiam

W dniu piątek, 20 grudnia 2019 07:59:37 UTC+1 użytkownik M.M. napisał:
> On Friday, December 20, 2019 at 7:39:45 AM UTC+1, godek...@gmail.com wrote:
> > Julia
> 
> Pierwszy link z googla trafia do forum:
> 
> https://4programmers.net/Forum/Inne/311782-julia_jezyk_do_obliczen_naukowych
> 
> Prawdę powiadają tam?

Z tego co widzę, wymieniają tam raczej różne opinie.

W każdym razie nie ulega wątpliwości, że z nowymi językami jest tak, że osoby przyzwyczajone do starych języków wolą pozostać przy starych językach. Są wyłomowcy, którzy rozwijają "własne języki", a niektórzy z nich mają nawet to szczęście, że im się udaje zbudować wokół tych języków jakąś społeczność.

Innymi słowy: nawet jeśli stworzono, to nikt i tak tego nie użyje.
(Chyba że jakaś duża korporacja zacznie to promować, jak to miało miejsce np. z językami w rodzaju Swift czy Kotlin)

Zaś co do Twojego pytania: "dlaczego nie stworzono łatwego języka programowania, który by miał opcję ręcznego zarządzania pamięcią, byłby kompilowany do ultra-wydajnego kodu maszynowego, no i który miałby składnię wzorowaną na C++, Javie, C# i z biblioteką standardową wzorowaną na QT?"

to chyba w zamyśle właśnie C++ ma być takim językiem. (i chyba nawet taki jest. Zwłaszcza jeśli używasz Qt)

Zresztą z tą opcją "ręcznego zarządzania pamięcią" to trochę jakby pytać 

"dlaczego nie stworzono łatwego języka programowania, który byłby trudny".

On Thu, 19 Dec 2019 18:26:22 -0800 (PST), M.M. wrote:

> Zastanawia mnie tylko dlaczego nie stworzono łatwego języka 
> programowania, który by miał opcję ręcznego zarządzania pamięcią, byłby
> kompilowany do ultra-wydajnego kodu maszynowego, no i który miałby składnię
> wzorowaną na C++, Javie, C# i z biblioteką standardową wzorowaną na QT? 

Sporo tych wymagań spełnia współczesny Object Pascal, czy to Delphi czy
FPC. 
Nie jest oczywiście C-like, ale zarówno niskopoziomowy, gdy trzeba, czyli
ręczne alokację pamięci, wskaźniki, wstawki ASM, jak i wysokopoziomowy, z
interfejsami, generykami, anomousami, rekordami z metodami, pełnym OOP i
RTTI. 
Jest łatwy i czytelny. 

-- 
pozdrawiam
Roman Tyczka

On Friday, December 20, 2019 at 12:43:48 PM UTC+1, Roman Tyczka wrote:
> On Thu, 19 Dec 2019 18:26:22 -0800 (PST), M.M. wrote:
> 
> > Zastanawia mnie tylko dlaczego nie stworzono łatwego języka 
> > programowania, który by miał opcję ręcznego zarządzania pamięcią, byłby
> > kompilowany do ultra-wydajnego kodu maszynowego, no i który miałby składnię
> > wzorowaną na C++, Javie, C# i z biblioteką standardową wzorowaną na QT? 
> 
> Sporo tych wymagań spełnia współczesny Object Pascal, czy to Delphi czy
> FPC. 
> Nie jest oczywiście C-like, ale zarówno niskopoziomowy, gdy trzeba, czyli
> ręczne alokację pamięci, wskaźniki, wstawki ASM, jak i wysokopoziomowy, z
> interfejsami, generykami, anomousami, rekordami z metodami, pełnym OOP i
> RTTI. 
> Jest łatwy i czytelny. 

Nie wiem czy to wszystko jest potrzebne w przeciętnej aplikacji. MOże zamiast
dostępu do ASM, by wstarczyły długie typy i kompilator z umiejętnością
optymalizowania? Mi się w Javie bardzo dobrze programowało. Int to był int,
string to był string, itd. Taka wydajniejsza Java z opcją ręcznego 
zarządzania pamięcią, kompilowana do kodu binarnego i bez przesady z
wirtualnymi funkcjami - była by blisko mojego ideału.

Pozdrawiam 

"M.M." <mmarszik@gmail.com> Wrote in message:
> W dzisiejszych czasach z jednej strony mamy tak zawiły, rozbudowany i zależnyod platformy język programowania jak C++, z drugiej strony mamy (chyba?) totalne przeciwieństwo tego języka, mianowicie język Python. [...] Nie wierzę, żeby pisanie w języku [...]


1. W dzisiejszych czasach mamy około 2000 różnych języków
 programowania. Takich jak np. Nemerle, Haskel, Verilog, C--,
 Forth, Lisp, Prolog czy nawet Bash. Nie licząc asemblerów - inny
 dla Z80, inny dla ARM itd.

2. Wiara to nawet przydatna rzecz. Ale ortogonalna do wiedzy.
 Pisanie w javopodobnym (a może po prostu w Javie, przecież sama
 Java jest chyba javopodobna, czyż nie?!) jest dla ponad 90%
 populacji tzw. homo sapiens awykonalne. Python niczego nie
 zmienia. Pisanie w Pythonie może być trudniejsze niż w C++.
 Python ma większy poziom abstrakcji, a większość ludzi ma
 problemy z myśleniem abstrakcyjnym. 


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

Roman Tyczka <noemail@because.no> Wrote in message:
> Sporo tych wymagań spełnia współczesny Object Pascal, czy to Delphi czyFPC.

Pascal jest równie ciekawy jak silnik Trabanta. Fajnie mieć coś
 takiego w garażu, ale nie należy się łudzić że ekologiczne, że
 będą do tego części zamienne, że to i tamto, bo to przecież
 niemieckie auto.

Pascal nie ma niczego więcej niż można to mieć w C++. W C++ są
 rzeczy których nie ma Pascal. Analogiczne porównanie pomiędzy
 Pascalem a Javą (Adą, ECMA Script, ...) daje to samo: Pascal nie
 ma niczego do zaoferowania poza nostalgią za latami
 70-tymi.


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

On Mon, 30 Dec 2019 07:26:25 +0100 (GMT+01:00), slawek wrote:

>> Sporo tych wymagań spełnia współczesny Object Pascal, czy to Delphi czyFPC.
> 
> Pascal jest równie ciekawy jak silnik Trabanta. Fajnie mieć coś
>  takiego w garażu, ale nie należy się łudzić że ekologiczne, że
>  będą do tego części zamienne, że to i tamto, bo to przecież
>  niemieckie auto.
> 
> Pascal nie ma niczego więcej niż można to mieć w C++. W C++ są
>  rzeczy których nie ma Pascal. Analogiczne porównanie pomiędzy
>  Pascalem a Javą (Adą, ECMA Script, ...) daje to samo: Pascal nie
>  ma niczego do zaoferowania poza nostalgią za latami
>  70-tymi.

Mowa o Object Pascalu, a nie Pascalu '70.

-- 
pozdrawiam
Roman Tyczka

Roman Tyczka <noemail@because.no> Wrote in message:
> On Mon, 30 Dec 2019 07:26:25 +0100 (GMT+01:00), slawek wrote:>> Sporo tych wymagań spełnia współczesny Object Pascal, czy to Delphi czyFPC.> > Pascal jest równie ciekawy jak silnik Trabanta. Fajnie mieć coś>  takiego w garażu, ale nie należy się łudzić że ekologiczne, że>  będą do tego części zamienne, że to i tamto, bo to przecież>  niemieckie auto.> > Pascal nie ma niczego więcej niż można to mieć w C++. W C++ są>  rzeczy których nie ma Pascal. Analogiczne porównanie pomiędzy>  Pascalem a Javą (Adą, ECMA Script, ...) daje to samo: Pascal nie>  ma niczego do zaoferowania poza nostalgią za latami>  70-tymi.

>Mowa o Object Pascalu, a nie Pascalu '70.-- pozdrawiamRoman Tyczka


Jeden pies: Cambridge Pascal, G Pascal, Turbo Pascal, Object
 Pascal, Delphi... 

No dobrze: dokręć do Trabanta alufelgi, dodaj spoilery i kubełkowe
 fotele z F1, zainstaluj turbosprężarkę... Dalej to będzie
 Trabant.

Pascal nie jest złym językiem. Po prostu są lepsze. A i niezbyt
 nadaje się do obliczeń numerycznych. Ma parę niezłych pomysłów,
 parę istotnych braków i parę dyskwalifikujących. Problem z Delphi
 można spowadzić do analogii "warto uczyć się języka polskiego bo
 kaszubski jest fajny". Tyle że dla np. przeciętnego kanadyjczyka
 uczenie się polskiego jest równie przydatne jak uczenie się
 Pascala. Nawet jeżeli byłby to dialekt kaszubski lub
 Delphi.

A czy ja znam Pascala? Przez ileś tam lat pisałem prawie tylko w
 Pascalu, więc coś tam jeszcze pamiętam ;)

Więc nie piszę z pozycji antyfana, ale raczej kogoś kto mając
 sentyment do " starych dobrych czasów" musi jednak dbać aby nie
 zostać leśnym dziadkiem nie potrafiącym nadążyć za
 postępem.


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

W dniu 20.12.2019 o 03:26, M.M. pisze:
> W dzisiejszych czasach z jednej strony mamy tak zawiły, rozbudowany i zależny
> od platformy język programowania jak C++, z drugiej strony mamy (chyba?)
> totalne przeciwieństwo tego języka, mianowicie język Python.
C++ powstał po co innego a Python po co innego. Wiem że w Pythonie da 
się napisać nawet aplikacje okienkową i będzie to działać tylko czy to 
jest dobry pomysł, albo inaczej widziałeś w Pythonie aplikację tak 
rozbudowaną jak w jeżykach kompilowanych? Ja nie widziałem i raczej nie 
zobaczę:)

Język skryptowy z językiem kompilowanym takie zestawienie nie ma sensu 
bo one powstały zupełnie do odmiennych rzeczy i pomimo tego że tak jak 
wspomniałem w Pythonie da się robić nawet aplikacje okienkowe tego robić 
się nie powinno

Tak jak teraz jest moda przenoszenia większości aplikacji do Weba to tak 
naprawdę żaden duży system np ERP nie będzie tak samo szybki jak ten 
napisany w języku kompilowanym a WEB w tych aplikacjach pozostaje 
dodatkiem bo posiada uboższe funkcje jak aplikacja kompilowana.

Znam kilka przykładów gdzie duże aplikacje zostały przeniesione na 
języki skryptowe i na WEB ale chodzi to dużo wolniej niż aplikacja w 
języku kompilowanym
  Rozumiem że
> było zapotrzebowanie na łatwy język programowania z przejrzystymi
> bibliotekami. Zastanawia mnie tylko dlaczego nie stworzono łatwego języka
> programowania, który by miał opcję ręcznego zarządzania pamięcią,

Co masz na myśli pisząc "Ręczne zarządzanie pamięcią"? Rozwiń... bo 
jeżeli masz na myśli alokowanie i zwalnianie pamięci to m.in zrobisz w 
pascalu. Ma to swoje wady i zalety ale tak zwany "Garbage collection", 
który jest implementowany w wielu językach ma więcej zalet niż wad

  byłby
> kompilowany do ultra-wydajnego kodu maszynowego, no i który miałby składnię
> wzorowaną na C++, Javie, C# i z biblioteką standardową wzorowaną na QT?

Chociaż byś napisał ultra wydajny kompilator który buduje taki kod 
maszynowy o jakim piszesz on w 95% albo i jeszcze więcej nie osiągnie 
takiego wydajnego kodu jaki ty sobie zakładasz. Powód? Człowiek on jest 
najsłabszym ogniwem bo to on piszę kod który jest na tyle niedoskonały 
by robić narzuty na wydajności. Jednocześnie ten sam kod pozwala się 
kompilować i działać tak jak jego twórca sobie zakładał. Ale to tylko 
jeden z aspektów pisania wydajnego kodu. Po drugiej stronie stoi mnogość 
urządzeń na którym dany kod w postaci oprogramowania ma pracować.

Doskonałym przykładem tutaj jest firma Apple która przeżywa rózne 
momenty w swoim istnieniu ale jest znana z tego że ich oprogramowanie 
działa dużo wydajniej niż odpowiedniki czy pierwowzory (jak kto woli) 
Microsoftu. Powód? Znany chyba wszystkim ich oprogramowanie działa na 
wąskiej gamie sprzętu, a to pozwala je zoptymalizować pod względem 
wydajności.

Niejednokrotnie ten sam kod ten, sam kompilator a różne platformy może 
się zdarzyć że będzie zachowywał się zupełnie inaczej na 2 różnych 
platformach

> Nie wierzę, żeby pisanie w języku javo-podobnym byłoby takie trudne do
> opanowania, albo proces tworzenia oprogramowania byłby wolniejszy nią w Pythonie.

Szybkość pisania oprogramowania w dzisiejszych czasach w bardzo małyn 
stopniu zależy od samego języka programowania. (No chyba że się ktoś 
uczy danego języka to wtedy ma to znaczenie)

Obecnie szybkość pisania danego oprogramowania zależy od ilości 
bibliotek które posiada dany język stąd tak popularne są dziś 
Java/JavaScript/Python/Ruby itd

Oczywiście każdy z tych języków pod względem wydajności jest różny.

By to zobrazować powrócę na chwilę do Pascala który to jest przez wielu 
nazywanym archaicznym językiem i pod względem liczby firm które tworzą w 
tym języku nowe rzeczy (Są takie :)) jest np stosunkowo mało chociaż kod 
maszynowy pascala jest pod względem szybkości na poziomie języka C 
(można znaleźć w sieci materiały to potwierdzające) Jednak C jest 
bardziej popularny niż Pascal i większości szybciej w nim napiszemy 
jakieś zaawansowane oprogramowanie szybciej niż w Pascalu bo mamy na 
starcie większą gamę bibliotek dostępnych do C niż do Pascala

> Jak ktoś nie chce się babrać w typowanie zmiennych, to język programowania
> może mieć wbudowany typ variant, a do klas dodatkowe słowo kluczowe dynamic -
> klasa z takim słowem kluczowym mogłaby mieć dynamicznie dodawane pola i
> metody - działałoby to też wolno, ale byłoby jako opcja, a nie przymus.

Podsumowując obecnie mamy dostępnych tyle języków że jest w czym wybrać 
i przymusu nie ma :) by coś stosować albo nie. Moim zdaniem pisanie 
kolejnego języka do czegoś co już istnieje mija się z celem. Brak jest 
moim zdaniem dobrych środowisk programistycznych do wykonania 
konkretnego typu zadań. Do wielu języków znajdziemy po 2 - 3 środowiska 
programistyczne np tak jest do C/C++, Javy ich środowiska są bardzo 
dobrę ale np do większości języków tzw. skryptowych nie ma dedykowanych 
środowisk praktycznie wcale te co są, są w większości pluginami do 
danego języka skryptowego gdzie po zainstalowaniu lub po długiej 
konfiguracji jakaś wtyczka staje się niekompatybilna i trafia cię szlag.

Pozdrawiam
J-23

Jest wiele mitów:

1. "Python to język skryptowy" - mit - podział na języki skryptowe
 i nie-skryptowe wymagałby zdefiniowania "skryptowości" - jak
 dotąd nikomu nie udało się tego dobrze zrobić. Czy Lua to język
 skryptowy? A Basic? Czym różni się semantycznie for z Javy, C++ i
 AWK? A taki Postscript to jest jaki?!

2. "Nie ma sensu robić programów z GUI w Pythonie" - mit - bo
 takie programy jest łatwiej zrobić niż w C++. Choćby w tym sensie
 że biblioteka Qt wymaga w przypadku C++ gimnastyki z
 metakompilatorem, a Python tego nie potrzebuje. Osobną sprawą
 jest kwestia czy każdy program powinien mieć GUI ? - ale
 odpowiedź na to nie zależy od języka.

3. "Python nie kompiluje się" - mit - są kompilatory Pythona.
 Ponadto podział języków na interpretowane (translatory) i
 kompilowane (kompilatory) jest dziś głupotą - mamy JIT i podobne
 techniki. A DLL dla Pythona są w natywnym.


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

On Mon, 30 Dec 2019 23:46:12 +0100 (GMT+01:00), slawek wrote:

>>Mowa o Object Pascalu, a nie Pascalu '70.-- pozdrawiamRoman Tyczka
> 
> 
> Jeden pies: Cambridge Pascal, G Pascal, Turbo Pascal, Object
>  Pascal, Delphi... 

To, że wszystkie te języki mają begin/end nie oznacza, że różni je tylko
nazwa.
 
> No dobrze: dokręć do Trabanta alufelgi, dodaj spoilery i kubełkowe
>  fotele z F1, zainstaluj turbosprężarkę... Dalej to będzie
>  Trabant.

Nie wiem czy ta analogia z trampkiem jest trafiona, w latach '70 były też
jakieś Mustangi czy inne Dodge, może tędy?
 
> Pascal nie jest złym językiem. Po prostu są lepsze. A i niezbyt
>  nadaje się do obliczeń numerycznych. 

Nikt nie twierdzi inaczej.

> Ma parę niezłych pomysłów,
>  parę istotnych braków i parę dyskwalifikujących. 

Mógłbyś te dyskwalifikujące wymienić? Pytam z ciekawości. Istotne braki też
jakieś tam znam, choć pewnie inne, bo niekoniecznie np. numeryka
rozbudowana jest mi osobiście potrzebna.

> Problem z Delphi  można spowadzić do analogii "warto uczyć się języka polskiego bo
>  kaszubski jest fajny". Tyle że dla np. przeciętnego kanadyjczyka
>  uczenie się polskiego jest równie przydatne jak uczenie się
>  Pascala. Nawet jeżeli byłby to dialekt kaszubski lub
>  Delphi.

Nikogo nie namawiam do nauki, odpowiedziałem tylko na pytanie.
 
> A czy ja znam Pascala? Przez ileś tam lat pisałem prawie tylko w
>  Pascalu, więc coś tam jeszcze pamiętam ;)
> 
> Więc nie piszę z pozycji antyfana, ale raczej kogoś kto mając
>  sentyment do " starych dobrych czasów" musi jednak dbać aby nie
>  zostać leśnym dziadkiem nie potrafiącym nadążyć za
>  postępem.

Tak, to też rozumiem i popieram.

-- 
pozdrawiam
Roman Tyczka

Roman Tyczka <noemail@because.no> Wrote in message:
> To, że wszystkie te języki mają begin/end nie oznacza, że różni je tylkonazwa.

Dlatego jeżeli już ma być begin-end to jednak Ada, a nie Algol czy
 Pascal.

>Mógłbyś te dyskwalifikujące wymienić? Pytam z ciekawości. Istotne braki teżjakieś tam znam, choć pewnie inne, bo niekoniecznie np. numerykarozbudowana jest mi osobiście potrzebna.

Brak dynamicznych tablic. Brak standardu wiązania z bibliotekami.
 Niemożliwość napisania własnej funkcji przyjmującej argumenty tak
 jak we wbudowanej write. Nieprzenośne przekazywanie funkcji jako
 parametru. Liczne, ale niekompatybilne, dialekty. Brak wyjątków.
 Brak namespaces. Zbyt mocne powiązanie z jednym producentem -
 vendor lock. Do tego np. błędna implementacja delay przez
 Borlanda - na szybkich (mniej więcej Pentium 1 @60 MHz) CPU
 programy po prostu nie działały bo startup code wkładał się z div
 by 0 na kalibracji delay. Trudności z użyciem dla low-level - w
 czym zwkłe C jest gorsze tylko od asemblera. Brak templates. Brak
 makrodefinicji. Brak STL. Brak fork. Brak arytmetyki wskaźników.
 Brak asm jako słowa kluczowego. Brak możliwości współpracy z
 Fortranem. Brak krótkiej ewaluacji. Brak refleksji. Brak
 dekoratorów.


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

W dniu 02.01.2020 o 09:46, slawek pisze:
> Jest wiele mitów:
> 
> 1. "Python to język skryptowy" - mit - podział na języki skryptowe
>   i nie-skryptowe wymagałby zdefiniowania "skryptowości" - jak
>   dotąd nikomu nie udało się tego dobrze zrobić. Czy Lua to język
>   skryptowy? A Basic? Czym różni się semantycznie for z Javy, C++ i
>   AWK? A taki Postscript to jest jaki?!

Skoro tak zadajesz pytanie to kompletnie albo nie wiesz co się dzieje w 
momencie kompilacji albo udajesz że nie wiesz - stawiam na to drugie :)

https://pl.wikipedia.org/wiki/Kompilator

Już prosta definicja z wiki (która jest uproszczona) pokazuje że zadanie 
pytania cytuje: "czym różni się for z javy, C++.." jest to nie właściwe 
pytanie. Bo odpowiedz jest bardzo prosta - sposobem wykonania tej 
instrukcji - efekt pozostaje taki sam w obu przypadkach ale sposób ich 
wykonania jest zupełnie różny. To właśnie dany sposób wykonania 
poszczególnych instrukcji sprawia że te instrukcje w danym języku będą 
wykonane szybciej inne wolniej... bardziej po chłopsku już się tego nie 
da chyba napisać :)

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.

> 
> 2. "Nie ma sensu robić programów z GUI w Pythonie" - mit - bo
>   takie programy jest łatwiej zrobić niż w C++. Choćby w tym sensie
>   że biblioteka Qt wymaga w przypadku C++ gimnastyki z
>   metakompilatorem, a Python tego nie potrzebuje. Osobną sprawą
>   jest kwestia czy każdy program powinien mieć GUI ? - ale
>   odpowiedź na to nie zależy od języka.

Okienka to tylko przykład. Jakoś nie widać oprogramowania w Pythonie np 
do obrobki Grafiki czy wideo. Znając Pythona wiem że żadne programy 
większego kalibru nie powstały i nie powstaną (No chyba ze coś znasz to 
podziel się linkiem)

Nie każdy program musi mieć GUI i powiem szczerze czy on jest czy go nie 
ma to i tak pozycji Pythona to nie zmienia - nadal pozostaje językiem w 
którym większość piszę proste skrypty i strony www.

Ma swoje zalety ale jednak przegrywa z językami kompilowanymi gdy np 
zależy nam na pisaniu coś pod konkretną platformę sprzętową

> 
> 3. "Python nie kompiluje się" - mit - są kompilatory Pythona.
>   Ponadto podział języków na interpretowane (translatory) i
>   kompilowane (kompilatory) jest dziś głupotą - mamy JIT i podobne
>   techniki.

Napisz jak to JIT działa wtędy będę wiedział czy wiesz o czym piszesz :)

Już wspomniałem że języki skryptowe jest ciężko odróżnić od wykonywanych 
na maszynach wirtualnych :)

Pamiętaj o tym pisząc o JIT :)
  A DLL dla Pythona są w natywnym.

W natywnym czym?

W Pythonie z tego co wiem można bez problemu użyć DLL napisanej np w C, 
ale pisać...? Może jest nigdy w te stronę się nie bawiłem ale stawiam na 
to że jeśli jest taka możliwość to czysty Python to nie jest :)

Pozdrawiam

W dniu 02.01.2020 o 18:16, slawek pisze:
> Roman Tyczka <noemail@because.no> Wrote in message:
>> To, że wszystkie te języki mają begin/end nie oznacza, że różni je tylkonazwa.
> 
> Dlatego jeżeli już ma być begin-end to jednak Ada, a nie Algol czy
>   Pascal.
> 
>> Mógłbyś te dyskwalifikujące wymienić? Pytam z ciekawości. Istotne braki teżjakieś tam znam, choć pewnie inne, bo niekoniecznie np. numerykarozbudowana jest mi osobiście potrzebna.
> 
> Brak dynamicznych tablic. Brak standardu wiązania z bibliotekami.
>   Niemożliwość napisania własnej funkcji przyjmującej argumenty tak
>   jak we wbudowanej write. Nieprzenośne przekazywanie funkcji jako
>   parametru. Liczne, ale niekompatybilne, dialekty. Brak wyjątków.
>   Brak namespaces. Zbyt mocne powiązanie z jednym producentem -
>   vendor lock. Do tego np. błędna implementacja delay przez
>   Borlanda - na szybkich (mniej więcej Pentium 1 @60 MHz) CPU
>   programy po prostu nie działały bo startup code wkładał się z div
>   by 0 na kalibracji delay. Trudności z użyciem dla low-level - w
>   czym zwkłe C jest gorsze tylko od asemblera. Brak templates. Brak
>   makrodefinicji. Brak STL. Brak fork. Brak arytmetyki wskaźników.
>   Brak asm jako słowa kluczowego. Brak możliwości współpracy z
>   Fortranem. Brak krótkiej ewaluacji. Brak refleksji. Brak
>   dekoratorów.
> 
> 

Strasznie ubogi ten Pascal z tego co piszesz :) Tylko widzisz większość 
rzeczy które tu wymieniłeś sa dostępne.

Błąd związany z Pentium o którym piszesz nie był domeną tylko Pascala w 
tamtym czasie - mało tego odpowiednie ustawienie flag kompilatora 
eliminowało ten problem.

Ale ok nie wcinam wam się w wątek - zrobiłem to tylko z powodu błędu na 
procesorach

Pozdrawiam

On Thursday, January 2, 2020 at 9:46:39 AM UTC+1, slawek wrote:
> Jest wiele mitów:
> 
> 1. "Python to język skryptowy" - mit - podział na języki skryptowe
>  i nie-skryptowe wymagałby zdefiniowania "skryptowości" - jak
>  dotąd nikomu nie udało się tego dobrze zrobić. Czy Lua to język
>  skryptowy? A Basic? Czym różni się semantycznie for z Javy, C++ i
>  AWK? A taki Postscript to jest jaki?!

Hmmm w sumie tak na szybko z rękawa nie umiem rzucić takiej definicji, aby
nikt się nie przyczepił. Może chodzi o to, że do 'języków skryptowych' nie
warto pisać kompilatora który zamieniałby go na kod maszynowy, bo wymagałoby
to wkompilowania interpretera? Każdy specyficzny element języka skryptowego
wymagałby call do interpretera, albo wstawienia ogromnej ilości kodu inline.

> 2. "Nie ma sensu robić programów z GUI w Pythonie" - mit - bo
>  takie programy jest łatwiej zrobić niż w C++. 

Nie przepadam za Pyhonem, ani nie mam doświadczenia w pisaniu aplikacji w
Pythonie, ale zgadzam się, że interfejs GUI w językach typu Python robi się
łatwiej, szybciej i w ogóle lepiej się do tego nadają. Po co w C++ się uganiać 
za wskaźnikami i martwić czy domyślny konstruktor wywoła się szybciej i
przydzieli pamięć pod listę z danymi do wyświetlenia w GUI... Ale nie
popadajmy w skrajność, dla kogoś kto ma wprawę takie uganianie w C++ jest 
nawet przyjemne i też robi się szybko. Podobno główną zaletą Pythona jest
to, że po zaledwie małym kursie można szybko pisać duże aplikacje. W C++
bez solidnego kursu i praktyki programować się zdecydowanie nie da. Czasami tu i
ówdzie można przeczytać, że Python jest dla naukowców. Jeśli chodzi o to, że
naukowiec żyje w swoim świecie, a od czasu do czasu musi szybko napisać 
jakiś programik sprawdzający jego teorię w praktyce - to się zgadzam. Po co
naukowiec miałby część swojej intelektualnej twórczości marnować na opanowywanie
ogromnej ilości szczegółów języka takiego jak C++? Natomiast gdy już naukowiec
zwraca się do programisty ze swoim problemem, to bardziej normalne 
wydaje się, że programista zaproponuje naukowcowi rozwiązanie uszyte na miarę
problemu i na miarę dostępnego sprzętu właśnie w C++ a nie w jakimś skrypciaku.

>  Choćby w tym sensie
>  że biblioteka Qt wymaga w przypadku C++ gimnastyki z
>  metakompilatorem, 

Jeden podpity do drugiego:
 - na rynku zrobili taką dziurę, wkłada się tam głowę i samo goli twarz.
 - no ale przecież każdy ma inną gębę!
 - ale tylko za pierwszym razem ;-)

Więc ta gimnastyka jest tylko za pierwszym razem gdy ktoś nie opanował 
metakompilera, kompilera zasobów, itd. Poza tym istnieje IDE o nazwie
QTCreator w którym (dziś, bo kiedyś się wywalało co rusz) można zbudować
naprawdę dużą aplikację i duże GUI nie rozumiejąc jak działa metakompiler a
nawet kompiler c++... w regularnym kodzie produkcyjnym nastawionym na 
stosunek funkcjonalności do nakładu pracy nawet nie jest wskazane rozumienie
szczegółów z qmake. Oczywiście gdy ktoś chce wycisnąć maksimum możliwości z
tych narzędzi to musi rozumieć jak one działają, ale taka konieczność 
zachodzi tylko w specyficznych aplikacjach.

>  a Python tego nie potrzebuje. Osobną sprawą
>  jest kwestia czy każdy program powinien mieć GUI ? - ale
>  odpowiedź na to nie zależy od języka.

No nie zależy od języka.


> 3. "Python nie kompiluje się" - mit - są kompilatory Pythona.

Słyszałem że jak się podaje typy i pisze w odpowiedni sposób to
można Pythona skompilować do C i potem do kodu maszynowego. Ale
to pisanie w odpowiedni sposób chyba oznacza rezygnację z wygód
jakie niosą kacze interpretowane języki ?

>  Ponadto podział języków na interpretowane (translatory) i
>  kompilowane (kompilatory) jest dziś głupotą - mamy JIT i podobne
>  techniki. A DLL dla Pythona są w natywnym.

Tak, ale nawet (bez sarkazmu) w wydajnej Javie JIT nie może wiele
zrobić gdy jest wirtualny call po nazwie i overloading na podstawie 
dynamicznych typów - w przypadku każdego wywołania.


Pozdrawiam

W dniu czwartek, 2 stycznia 2020 20:30:52 UTC+1 użytkownik J-23 napisał:
> W dniu 02.01.2020 o 09:46, slawek pisze:
> > Jest wiele mitów:
> > 
> > 1. "Python to język skryptowy" - mit - podział na języki skryptowe
> >   i nie-skryptowe wymagałby zdefiniowania "skryptowości" - jak
> >   dotąd nikomu nie udało się tego dobrze zrobić. Czy Lua to język
> >   skryptowy? A Basic? Czym różni się semantycznie for z Javy, C++ i
> >   AWK? A taki Postscript to jest jaki?!
> 
> Skoro tak zadajesz pytanie to kompletnie albo nie wiesz co się dzieje w 
> momencie kompilacji albo udajesz że nie wiesz - stawiam na to drugie :)
> 
> https://pl.wikipedia.org/wiki/Kompilator
> 
> Już prosta definicja z wiki (która jest uproszczona) pokazuje że zadanie 
> pytania cytuje: "czym różni się for z javy, C++.." jest to nie właściwe 
> pytanie. Bo odpowiedz jest bardzo prosta - sposobem wykonania tej 
> instrukcji - efekt pozostaje taki sam w obu przypadkach ale sposób ich 
> wykonania jest zupełnie różny. To właśnie dany sposób wykonania 
> poszczególnych instrukcji sprawia że te instrukcje w danym języku będą 
> wykonane szybciej inne wolniej... bardziej po chłopsku już się tego nie 
> da chyba napisać :)

Bo i rozumowanie jest raczej "chłopskie".

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

A do których języków nie potrzeba środowiska uruchomieniowego?

"Podział" na "języki skryptowe i kompilowane" z logicznego punktu widzenia nie jest podziałem dychotomicznym.
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)

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

Prototypowe języki skryptowe to języki powłoki (np. bash albo DOSowe batche albo skrypty w PowerShellu).

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.

W dalszej kolejności mamy języki takie jak Perl czy AWK, które są uznawane za skryptowe, bo są podobne do skryptowych.
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".

Znam ludzi, którzy woleliby do tych samych celów użyć Haskella (który jest "mocno kompilowany").

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żą).

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

No, a PostScript jest oczywiście stosowy.

J-23 <Baczeklu@poczta.fm> Wrote in message:
> Strasznie ubogi ten Pascal z tego co piszesz :) Tylko widzisz większość rzeczy które tu wymieniłeś sa dostępne.Błąd związany z Pentium o którym piszesz nie był domeną tylko Pascala w tamtym czasie.

Tak, większość z tych rzeczy była dostępna w C++ w XX wieku. W
 Pascalu/Delphi nie. Jeżeli coś pomyliłem, to napisz konkretnie
 co. Może Pascal ma obsługę wyjątków? Nie ma? No właśnie. A może
 nie jest prawdą że co dialekt Pascala to w inny sposób
 przekazywało się funkcję/procedurę jako parametr (mały myk - były
 wersje, bodajże Turbo Pascal, gdzie to w ogóle było niemożliwe)?
 A może jest już STL dla Pascala? To może można redefiniować
 operatory w Pascalu?!

Mylisz też, misiaczku, tzw. Pentium Bug z błedem delay. Ten
 pierwszy był błędem samego CPU - Intel Pentium we wczesnej wersji
 - instrukcja fdiv mogła, w pewnych okolicznościach przyrody,
 "dawać mniej dokładne wyniki" - np. zamiast 4.0 wychodziło
 5.0.

Ten drugi to błąd w kodzie startup Turbo Pascala - program na
 dzień dobry robił pustą pętlę z n iteracjami mierząc ile to czasu
 t zajmuje, potem dzielił n/t po to aby skalibrować działanie
 funkcji delay. Dowcip w tym że przy szybkich procesorach, takich
 jak Pentium, wychodziło t = 0.0 z oczywistym efektem. Co
 powodowało że nieoczekiwanie wszystkie programy (exe) zrobione w
 Turbo Pascalu przestawały dawać się uruchamiać. Oczywiście,
 powstał patch - nadpisujący kod startowy w exe-kach. Tyle że były
 to czasy gdy nie było aktualizacji Windows trzy razy na godzinę.
 


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

godek.maciek@gmail.com Wrote in message:
> "Podział" na "języki skryptowe i kompilowane" z logicznego punktu widzenia nie jest podziałem dychotomicznym.

Exactly.

Dodam, że nigdzie nie znalazłem skutecznej definicji kryterium co
 jest "językiem skryptowym". Tzn. takiej, że mając język X można
 zastosować je do jednoznacznego rozstrzygnięcia czy język jest
 skryptowy czy nie jest.

Czyli "skryptowy" to słowo nie niosące żadnego konkretnego
 znaczenia, rodzaj "yyyeee" czy "hmmm".


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

"M.M." <mmarszik@gmail.com> Wrote in message:
> Podobno główną zaletą Pythona jestto, że po zaledwie małym kursie można szybko pisać duże aplikacje. W C++bez solidnego kursu i praktyki programować się zdecydowanie nie da. Czasami tu iówdzie można przeczytać, że Python...


1. IMO Python jest niezbyt dobry dla programów mających ponad
 100000 LOC (nie licząc bibliotek i cudzych modułów). Idealnie
 program w Pythonie to jakieś 2000 do 5000 LOC robiące to do czego
 w C++ potrzeba byłoby jakiegoś giganta na pół miliona linii kodu.
 Oczywiście całkiem konkretne rzeczy da się zrobić w np. 50
 linijkach lub mniej. Przykładowo: zassać dane z bazy, zrobić
 obliczenia i narysować publish-ready wykresy.

2. W C++ da się programować na poziomie C. Tak m.i. programują
 mikrokontrolery elektronicy - udając że nie ma OOP, STL, new i
 nawet const.

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.
 W C++ też dałoby się to /jakoś/ zrobić. Tyle że w Pythonie taki
 poziom abstrakcji jest czymś zupełnie normalnym.

4. Python ma parę PASKUDNYCH wad.


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

W dniu 03.01.2020 o 00:20, slawek pisze:
> J-23 <Baczeklu@poczta.fm> Wrote in message:
>> Strasznie ubogi ten Pascal z tego co piszesz :) Tylko widzisz większość rzeczy które tu wymieniłeś sa dostępne.Błąd związany z Pentium o którym piszesz nie był domeną tylko Pascala w tamtym czasie.
> 
> Tak, większość z tych rzeczy była dostępna w C++ w XX wieku. W
>   Pascalu/Delphi nie. Jeżeli coś pomyliłem, to napisz konkretnie
Właśnie o to chodzi że większość tych rzeczy które wymieniłeś byly 
jeszcze w latach 90 tych
>   co. Może Pascal ma obsługę wyjątków? Nie ma?
Nie ma obsługi wyjątków od kiedy :P?? Bo są od dawna nawet wersji nie ma 
co przytaczać :P ale try...except...finally było na bank w latach 90 
tych juz :)
  No właśnie. A może
>   nie jest prawdą że co dialekt Pascala to w inny sposób
>   przekazywało się funkcję/procedurę jako parametr (mały myk - były
>   wersje, bodajże Turbo Pascal, gdzie to w ogóle było niemożliwe)?

Dialekt Pascala się zmieniał i zmienia nadal ale inne języki i ich 
dialekty też się zmieniają - proste (także marny zarzut że język się 
rozwija)

>   A może jest już STL dla Pascala? 
Są :) nie są tak rozwinięte jak w C++ ale są :)

To może można redefiniować
>   operatory w Pascalu?!
Tego brak
> 
> Mylisz też, misiaczku, tzw. Pentium Bug z błedem delay. Ten
>   pierwszy był błędem samego CPU - Intel Pentium we wczesnej wersji
zgadza się i wystarczyła wstawka asembler owa lub pogrzebanie z 
przełącznikami kompilatora by to naprawić. Nawet pamiętam do dziś że 
zrobiłem sobie narzędzie gdzie w lini komend podawałem ścieżkę programu 
i w ten sposób odpalałem program i tego problemu nie było
>   - instrukcja fdiv mogła, w pewnych okolicznościach przyrody,
>   "dawać mniej dokładne wyniki" - np. zamiast 4.0 wychodziło
>   5.0.
> 
> Ten drugi to błąd w kodzie startup Turbo Pascala - program na
>   dzień dobry robił pustą pętlę z n iteracjami mierząc ile to czasu
>   t zajmuje, potem dzielił n/t po to aby skalibrować działanie
>   funkcji delay. Dowcip w tym że przy szybkich procesorach, takich
>   jak Pentium, wychodziło t = 0.0 z oczywistym efektem. Co
>   powodowało że nieoczekiwanie wszystkie programy (exe) zrobione w
>   Turbo Pascalu przestawały dawać się uruchamiać. Oczywiście,
>   powstał patch - nadpisujący kod startowy w exe-kach. Tyle że były
>   to czasy gdy nie było aktualizacji Windows trzy razy na godzinę.

O tym samym mówimy :) ja napisałem to raz i miałem z głowy. Właśnie w 
taki sposób jak opisałem powyżej

Dodam nawet że miło wspominam ten czas bo z tego w tamtym czasie miałem 
spory grosz :)
>   
> 
> 
> ----Android NewsGroup Reader----
> http://usenet.sinaapp.com/
> 

On Friday, January 3, 2020 at 1:18:08 AM UTC+1, slawek wrote:
> "M.M." <m@g.c> Wrote in message:
> > Podobno główną zaletą Pythona jestto, że po zaledwie małym kursie można szybko pisać duże aplikacje. W C++bez solidnego kursu i praktyki programować się zdecydowanie nie da. Czasami tu iówdzie można przeczytać, że Python...
> 
> 
> 1. IMO Python jest niezbyt dobry dla programów mających ponad
>  100000 LOC (nie licząc bibliotek i cudzych modułów). 

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?

> Idealnie
>  program w Pythonie to jakieś 2000 do 5000 LOC robiące to do czego
>  w C++ potrzeba byłoby jakiegoś giganta na pół miliona linii kodu.

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.

>  Oczywiście całkiem konkretne rzeczy da się zrobić w np. 50
>  linijkach lub mniej. Przykładowo: zassać dane z bazy, zrobić
>  obliczenia i narysować publish-ready wykresy.

W C++ też to można zrobić w 50 linijkach, kwestia bibliotek.

 
> 2. W C++ da się programować na poziomie C. Tak m.i. programują
>  mikrokontrolery elektronicy - udając że nie ma OOP, STL, new i
>  nawet const.

Osobiście programowałem w C++ na mikrokontrolery. Dzięki szablonom
miałem prawie od kopa 3 wersje swojej biblioteki, wielkość kodu w
zależności od wersji biblioteki różniła się wielokrotnie, mogłem
wybrać najmniejszy kod. W C bym musiał nieźle się nagimnastykować żeby
uzyskać taki efekt.


> 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; }


>  W C++ też dałoby się to /jakoś/ zrobić. Tyle że w Pythonie taki
>  poziom abstrakcji jest czymś zupełnie normalnym.

Hmmmm to prawda.


> 4. Python ma parę PASKUDNYCH wad.

Ja nie wiem.

Pozdrawiam

On Thu, 2 Jan 2020 18:16:45 +0100 (GMT+01:00), slawek wrote:

>> To, że wszystkie te języki mają begin/end nie oznacza, że różni je tylkonazwa.
> 
> Dlatego jeżeli już ma być begin-end to jednak Ada, a nie Algol czy
>  Pascal.
> 
>>Mógłbyś te dyskwalifikujące wymienić? Pytam z ciekawości. Istotne braki teżjakieś tam znam, choć pewnie inne, bo niekoniecznie np. numerykarozbudowana jest mi osobiście potrzebna.

Jak pisałem poprzednio, gdy mówimy o dzisiejszym Object Pascalu to:
 
> Brak dynamicznych tablic. 

są oczywiście i to od dawna

> Brak standardu wiązania z bibliotekami.

nie wiem na czym standard miałby polegać, ale biblioteki z innych języków
da się używać, a także linkować pliki .obj

>  Niemożliwość napisania własnej funkcji przyjmującej argumenty tak
>  jak we wbudowanej write. 

To prawda, choć jeśli dopuścić zapis wywołania z tablicą:

DoJob([1, 'text', 6.5]);
DoJob(['text', 15]);

to się da.

>  Nieprzenośne przekazywanie funkcji jako
>  parametru. 

Typy funkcyjne/proceduralne są od bardzo dawna, od dekady są też metody
anonimowe, więc można ich wszystkich używać jako parametrów

> Liczne, ale niekompatybilne, dialekty. 

To prawda.

> Brak wyjątków.

Są od dekad.

>  Brak namespaces. 

Tak, tego brakuje

> Zbyt mocne powiązanie z jednym producentem -  vendor lock. 

To nie jest argument przeciw językowi.

>  Do tego np. błędna implementacja delay przez
>  Borlanda - na szybkich (mniej więcej Pentium 1 @60 MHz) CPU
>  programy po prostu nie działały bo startup code wkładał się z div
>  by 0 na kalibracji delay. 

Problem sprzed ponad 20 lat - nieistniejący.

> Trudności z użyciem dla low-level - w czym zwkłe C jest gorsze tylko od asemblera. 

Czyli konkretnie co?

>  Brak templates. Brak makrodefinicji. 

Są za to generyki.

> Brak STL. 

Jest Spring:
https://spring4d.4delphi.com/docs/master/Html/index.htm?Spring.Base.htm

> Brak fork. 

Fakt

> Brak arytmetyki wskaźników.

Od ponad dekady jest 

https://helloacm.com/pointer-arithmetic-in-delphi/

>  Brak asm jako słowa kluczowego. 

Od dekad:

http://docwiki.embarcadero.com/RADStudio/Rio/en/Assembly_Expressions

> Brak możliwości współpracy z Fortranem. 

To jest jakiś uniwersalny wymóg dla języków?

> Brak krótkiej ewaluacji. 

Od dekad:

http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/compdirsbooleanshortcircuitevaluation_xml.html

> Brak refleksji. 

http://robstechcorner.blogspot.com/2009/09/delphi-2010-rtti-basics.html

> Brak dekoratorów.

Jeśli masz na myśli to co w Javie nazywa się annotations, to są attributes:

http://docwiki.embarcadero.com/RADStudio/Rio/en/Attributes_and_RTTI

-- 
pozdrawiam
Roman Tyczka

W dniu piątek, 3 stycznia 2020 00:35:32 UTC+1 użytkownik slawek napisał:

> 
> Dodam, że nigdzie nie znalazłem skutecznej definicji kryterium co
>  jest "językiem skryptowym". Tzn. takiej, że mając język X można
>  zastosować je do jednoznacznego rozstrzygnięcia czy język jest
>  skryptowy czy nie jest.
>
> Czyli "skryptowy" to słowo nie niosące żadnego konkretnego
>  znaczenia, rodzaj "yyyeee" czy "hmmm".

Nie. "Skryptowy" to pojęcie oparte na prototypie i podobieństwie względem prototypu. Nie ulega najmniejszej wątpliwości, że języki powłoki systemu to języki skryptowe.

O ile jednak ma sens mówienie, że dany język w swoich typowych zastosowaniach jest skryptowy (czyli np. "jeżeli chcesz pisać programy, które w jakiś sposób naśladują twoje interakcje z komputerem, rozsądnie wybrać taki a taki język"), o tyle raczej nie ma sensu mówienie o językach "nie-skryptowych". (W C możesz zrobić wszystko to, co w bashu. Tyle że opeartory w rodzaju <, > czy >> są dużo prostsze w użyciu, niż interfejsy fopen, fread i fwrite)

Ale to coś więcej, niż "yyyeee" czy "hmmm".

godek.maciek@gmail.com Wrote in message:
> Nie ulega najmniejszej wątpliwości, że języki powłoki systemu to języki skryptowe.

No to popatrz - VBA nie jest skryptowy. A VBS jest. C jest
 skryptowy, bo jest csh, czyli C-shell. A Javascript nie jest
 skryptowy, bo to nie język powłoki systemu.

> W C możesz zrobić wszystko to, co w bashu. Tyle że opeartory w rodzaju <, > czy >> są dużo prostsze w użyciu, niż interfejsy fopen, fread i fwrite.

No cóż, nie bardzo kumam o co ci chodzi - zwłaszcza że bash jest
 napisany w C - więc nie da się zrobić w bash tego co niemożliwe w
 C. Owszem, w C można zrobić to czego nie da się zrobić w bash.
 Np. napisać procedurę obsługi przerwania.

W dniu piątek, 3 stycznia 2020 18:12:41 UTC+1 użytkownik slawek napisał:
> > Nie ulega najmniejszej wątpliwości, że języki powłoki systemu to języki skryptowe.
> 
> No to popatrz - VBA nie jest skryptowy. A VBS jest.

I w czym problem?

> C jest  skryptowy, bo jest csh, czyli C-shell.

Wiesz w ogóle o czym mówisz?

Zobaczmy. 

$ csh

% int x = 5;
int: Command not found

% int f(void) { return 5; }
Badly placed ()'s.

No rzeczywiście.

> A Javascript nie jest skryptowy, bo to nie język powłoki systemu.

No nie jest. I co teraz?

> > W C możesz zrobić wszystko to, co w bashu. Tyle że opeartory w rodzaju <, > czy >> są dużo prostsze w użyciu, niż interfejsy fopen, fread i fwrite.
> 
> 
> No cóż, nie bardzo kumam o co ci chodzi - zwłaszcza że bash jest
>  napisany w C - więc nie da się zrobić w bash tego co niemożliwe w
>  C. Owszem, w C można zrobić to czego nie da się zrobić w bash.
>  Np. napisać procedurę obsługi przerwania.

Faktycznie nie bardzo kumasz o co mi chodzi.
Może przeczytaj jeszcze kilka razy to, co napisałem.
(Albo poczekaj aż będziesz miał zdaną maturę)

godek.maciek@gmail.com Wrote in message:
> Faktycznie nie bardzo kumasz o co mi chodzi.Może przeczytaj jeszcze kilka razy to, co napisałem.(Albo poczekaj aż będziesz miał zdaną maturę)

To przeczytaj co piszą w Wikipedii:

"Język skryptowy (ang. script language) – język
 programowania obsługujący skrypty[1]. Często służący do
 kontrolowania określonej aplikacji.

Skrypty – programy napisane w językach skryptowych, ”


Nawet jeżeli nie masz matury to powinieneś wychwycić że taka
 definicja skryptowości kupy się nie trzyma.
 
I nie spinaj się tak bardzo, bo od tego tylko hemoroidy ci urosną.

W dniu piątek, 3 stycznia 2020 19:17:58 UTC+1 użytkownik slawek napisał:

> > Faktycznie nie bardzo kumasz o co mi chodzi.Może przeczytaj jeszcze kilka razy to, co napisałem.(Albo poczekaj aż będziesz miał zdaną maturę)
> 
> To przeczytaj co piszą w Wikipedii:
> 
> "
> Język skryptowy (ang. script language) – język
>  programowania obsługujący skrypty[1]. Często służący do
>  kontrolowania określonej aplikacji.
> 
> Skrypty – programy napisane w językach skryptowych, ”
> 
> 
> Nawet jeżeli nie masz matury to powinieneś wychwycić że taka
>  definicja skryptowości kupy się nie trzyma.

Chyba przeoczyłeś: "przeznaczone do wykonywania w specjalnych środowiskach uruchomieniowych automatyzujących wykonywanie zadań, które alternatywnie mogą być wykonywane jedno po drugim przez użytkownika".
Może jednak lepiej zaczekaj do tej matury.

> I nie spinaj się tak bardzo, bo od tego tylko hemoroidy ci urosną.

Masz w tej kwestii jakieś doświadczenia, którymi chciałbyś się tutaj podzielić?

W dniu 02.01.2020 o 21:58, godek.maciek@gmail.com pisze:
> A do których języków nie potrzeba środowiska uruchomieniowego?
Chyba inaczej rozumiemy środowiska uruchomieniowe.

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. Natomiast odróżnienie teraz kodu skompilowanego od języka 
skryptowego moim zdaniem nie jest problemem. O tym za chwile niżej.
> 
> "Podział" na "języki skryptowe i kompilowane" z logicznego punktu widzenia nie jest podziałem dychotomicznym.
Tak i nie :)
> 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"

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

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

> 
> 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"
> 
> 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
- sposób dostarczenia kodu
- wyizolowanego środowiska uruchomieniowego uniezależnionego od 
systemu/sprzętu
Potraktowanie skryptu JTL czy innymi konwerterami nie zmieni cechy 
języka co najwyżej przygotuje duży program wynikowy połączony z tym 
skryptem co pozwoli na jego uruchomienie jak skompilowanego programu


> W dalszej kolejności mamy języki takie jak Perl czy AWK, które są uznawane za skryptowe, bo są podobne do skryptowych.
Nie są podobne tylko są skryptowe :)
> 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_interpretowany
https://pl.wikipedia.org/wiki/J%C4%99zyk_skryptowy
> 
> Znam ludzi, którzy woleliby do tych samych celów użyć Haskella (który jest "mocno kompilowany").

Tego nie znam więc się nie wypowiem
> 
> 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

> No, a PostScript jest oczywiście stosowy.

Szczerze powiem:) nie wiem nigdy nie miałem potrzeby tego używać :)

Pozdrawiam
J-23

godek.maciek@gmail.com Wrote in message:
> Masz w tej kwestii jakieś doświadczenia, którymi chciałbyś się tutaj podzielić?

A widzisz, misiaczku, mam. Żyję już dostatecznie długo, aby z
 daleka rozpoznać osobniki nadęte, głupie i bez fantazji.
 Chorobliwie próbujące udowodnić sobie że są samcami alfa.
 Misiaczku, takich jak ty to nawet nie warto opierdalać.

Anyway, przekonałeś nas wszystkich że twoim największym
 osiągnięciem było zdanie matury. Czyli czego? Jakiś język
 ojczysty, język obcy... być może matematyka (ale to akurat
 niepewne)... Wic w tym że nie informatyka. Czyli ta twoja rzekoma
 matura nijak się ma do tego jak oceniać cię jako programistę.
 

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.

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

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

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

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

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

Nie rozumiem.
(Ale - gwoli ścisłości - interpreterami. Interpretator to osoba.)

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

> - sposób dostarczenia kodu

Czyli jak przekazuję kod źrodłowy programu w C, to język C staje się skryptowy?

> - wyizolowanego środowiska uruchomieniowego uniezależnionego od 
> systemu/sprzętu

Czyli C# jest skryptowy?

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

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

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

W dniu piątek, 3 stycznia 2020 21:22:40 UTC+1 użytkownik slawek napisał:
> > Masz w tej kwestii jakieś doświadczenia, którymi chciałbyś się tutaj podzielić?
> 
> 
> A widzisz, misiaczku, mam. Żyję już dostatecznie długo, aby z
>  daleka rozpoznać osobniki nadęte, głupie i bez fantazji.

16 lat to nie tak znowu długo. Najwidoczniej dla niektórych zbyt mało żeby nauczyć się odróżniać rzeczywistość od swoich urojeń.

> Anyway, przekonałeś nas wszystkich że twoim największym
>  osiągnięciem było zdanie matury. Czyli czego? Jakiś język
>  ojczysty, język obcy... być może matematyka (ale to akurat
>  niepewne)... Wic w tym że nie informatyka. Czyli ta twoja rzekoma
>  matura nijak się ma do tego jak oceniać cię jako programistę.

Jeżeli jest to istotne, to moją pracę magisterską z informatyki można sobie sciągnąć i przeczytać:

https://github.com/panicz/master-thesis/

Może nie jest to nic wielkiego, ale, jak to mówią,
zawsze coś.

Trzymam kciuki za egzamin maturalny.

W dniu 03.01.2020 o 21:27, godek.maciek@gmail.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_interpretowany
>> 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

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?

> > 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 :)

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

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.

Przykładowo, pierwsze implementacje JavaScriptu to były interpretery.
Teraz przeglądarki mają swoje JIT-kompilatory, które generują kod maszynowy.
Mnie z punktu widzenia użytkownika języka (albo użytkownika programu) w ogóle to nie obchodzi.

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

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

> >> - 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_interpretowany
> >> 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]

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

Jeżeli tak, to jakie cechy musi spełniać ten interpreter, żeby interpretowany przez niego język był skryptowy?

godek.maciek@gmail.com Wrote in message:
> Jeżeli jest to istotne, to moją pracę magisterską z informatyki można sobie sciągnąć i przeczytać:https://github.com/panicz/master-thesis/Może nie jest to nic wielkiego, ale, jak to mówią,zawsze coś.Trzymam kciuki za egzamin maturalny.

Misiaczku, magisterka zrobiona dwa lata temu na prowincjonalnym UG
 stawia cię na pozycji młodego, nieopierzonego, leszczyka. A, co
 przykro stwierdzić, matura sprzed 7 lat nie ma wartości - już się
 jej nie kupowało na Stadionie X Lecia - ale poziom nie ten co
 przed wojną. I nie żebym miał jakieś uprzedzenia do ludzi z
 Tczewa.

Dzięki za numer indeksu, zobaczymy oceny przy jakiejś okazji.

W dniu sobota, 4 stycznia 2020 01:15:44 UTC+1 użytkownik slawek napisał:
> > Jeżeli jest to istotne, to moją pracę magisterską z informatyki można sobie sciągnąć i przeczytać:https://github.com/panicz/master-thesis/Może nie jest to nic wielkiego, ale, jak to mówią,zawsze coś.Trzymam kciuki za egzamin maturalny.
> 
> 
> magisterka zrobiona dwa lata temu na prowincjonalnym UG
>  stawia cię na pozycji młodego, nieopierzonego, leszczyka.

?

Może najpierw pójdź na studia wyższe, a dopiero potem się wypowiadaj.

> A, co przykro stwierdzić, matura sprzed 7 lat nie ma wartości - już się
>  jej nie kupowało na Stadionie X Lecia

?

> I nie żebym miał jakieś uprzedzenia do ludzi z
>  Tczewa.

?
 
> Dzięki za numer indeksu, zobaczymy oceny przy jakiejś okazji.

Mam się bać?

W dniu 04.01.2020 o 00:55, godek.maciek@gmail.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_interpretowany
>>>> 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 :)

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"

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

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

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

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

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

No to Python jest tutaj kontrprzykładem.

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

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

> > A co jeżeli przed wykonaniem programu najpierw go skompiluje i zapisze w jakimś swoim cache'u i wykona wersę skompilowaną?
> > (Tak np. robi GUILE)
> > 
> Nie używałem tego nie wiem. Ale jak to działa jak JTL to to nic nie 
> zmieni, bo nadal będzie działać w odizolowanym środowisku. Rozumiem że 
> sugerujesz że to działa inaczej?

Co to jest JTL?

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

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

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

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

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

Nie zauważam.
Zauważam, że języki skryptowe służą do pisania skryptów.
A to, czy te skrypty są przed uruchomieniem kompilowane przez środowisko, czy interpretowane, jest szczegółem, który jest dla mnie niewidoczny, i który bynajmniej mnie nie obchodzi.

godek.maciek@gmail.com Wrote in message:
> Może najpierw pójdź na studia wyższe, a dopiero potem się wypowiadaj.

No cóż - wypowiadam się.

Misiaczku, dyplom kałamarza czy magistra to ma około 21% obywateli
 RP. A tu - na forum - bezpieczniej można założyć że
 każdy.

W dniu sobota, 4 stycznia 2020 09:26:24 UTC+1 użytkownik slawek napisał:
> > Może najpierw pójdź na studia wyższe, a dopiero potem się wypowiadaj.
> 
> No cóż - wypowiadam się.

Trudno nie zauważyć.
Podobnie jak to, że nie masz pojęcia o tematach, na które się wypowiadasz.

> Misiaczku

"Misiaczku" to możesz mówić do kolesi, którym ssiesz pałki na dobranoc.

> dyplom kałamarza czy magistra to ma około 21% obywateli
>  RP. A tu - na forum - bezpieczniej można założyć że
>  każdy.

Może zdaj maturę i wtedy porozmawiamy.

godek.maciek@gmail.com Wrote in message:
> Może zdaj maturę i wtedy porozmawiamy

A może przestaniesz się napinać, bo na razie to jedyne co
 pokazujesz to niski poziom kultury osobistej i jeszcze niższa
 inteligencja?

Przez dwa lata od magisterki nie zrobiłeś niczego ciekawego. Za
 szczyt swoich osiągnięć uważasz zdanie matury. Jako nick na
 GitHub wybrałeś sobie "paniczyk" czy jakoś tak. Nawet porządnie
 przeklinać nie umiesz. Cóż, całe szczęście że nie jesteś moim
 synem, bo byłoby mi zwyczajnie wstyd mieć takiego potomka. Jeżeli
 taki jak ty poziom mają inni "informatycy" z UG - to raczej nie
 powinni liczyć na cokolwiek innego niż "projektowanie stron
 internetowych".

W dniu sobota, 4 stycznia 2020 10:51:26 UTC+1 użytkownik slawek napisał:

> > Może zdaj maturę i wtedy porozmawiamy
> 
> A może przestaniesz się napinać, bo na razie to jedyne co
>  pokazujesz to niski poziom kultury osobistej i jeszcze niższa
>  inteligencja?

O tyle jednak wyższa od Twojej, że mam zdaną maturę.

>  Przez dwa lata od magisterki nie zrobiłeś niczego ciekawego.

Skąd wiesz, co zrobiłem, a czego nie zrobiłem, przez dwa lata od magisterki?

> Za szczyt swoich osiągnięć uważasz zdanie matury.

No nie, nie uważam.
Uważam, że Tobie by się przydało nabyć kompetencję rozumienia czytanego tekstu, i tyle.

> Jako nick na GitHub wybrałeś sobie "paniczyk" czy jakoś tak.

No widzisz. A Ty nawet nie masz konta na githubie.

> Nawet porządnie
>  przeklinać nie umiesz. Cóż, całe szczęście że nie jesteś moim
>  synem, bo byłoby mi zwyczajnie wstyd mieć takiego potomka.

Też bym nie chciał żeby moim ojcem był przemądrzały 16-latek który zwraca się do obcych mężczyzn per "misiaczku".

W dniu sobota, 4 stycznia 2020 09:50:08 UTC+1 użytkownik godek...@gmail.com napisał:
> W dniu sobota, 4 stycznia 2020 09:26:24 UTC+1 użytkownik slawek napisał:
> > > Może najpierw pójdź na studia wyższe, a dopiero potem się wypowiadaj.
> > 
> > No cóż - wypowiadam się.
> 
> Trudno nie zauważyć.
> Podobnie jak to, że nie masz pojęcia o tematach, na które się wypowiadasz.
> 
> > Misiaczku
> 
> "Misiaczku" to możesz mówić do kolesi, którym ssiesz pałki na dobranoc.
> 


lol, widze ze kolega zerwal ze swoja filozofia by limitowac sie w tekstach (gdy ja pisalem o krowach robiacych na dywan w bibliotece) ;c - w zasadzie to nawet dobrze bo smiesznie sie takie cos czyta (choc to zalezy od szczegolow bo
czasem mozna tez popasc w depresje)

user slawek jest dziwny, wiele lat temu 
(z 10 pewnie albo i wiecej (?) nie jestem pewien costam pisaywal z sensem ostatnio
cos gorzej mu czasem wychodzi - sam jednak staram sie (czy moze staralbym gdybym tu wiecej pisywac) limitowac w wyrazaniu krytyki bo zauwazylem ze niektorzy przesadnia na nia reaguja 
(nop kiedys mnie wpieniel user AL z ameryki, ktory costam pisywal z sensem i 
po skrytykowaniu czegos przeze mnie odszedl z grupy co nie bylo ok bo moim zdaniem bylo przesadna reakcja

- z drugiej strony nieststy na odwrot niejacy zasyfiacze i patologiczni oglupiacze rozwalali ta grupe pewnie nie mniej niz lunatyczny przyglup-nudziarz broneq i ciezko bylo czegos nie powiedziec, choc i to niewiele pomagalo,

smutne zycie, co robic)





> > dyplom kałamarza czy magistra to ma około 21% obywateli
> >  RP. A tu - na forum - bezpieczniej można założyć że
> >  każdy.
> 
> Może zdaj maturę i wtedy porozmawiamy.

W dniu sobota, 4 stycznia 2020 13:39:52 UTC+1 użytkownik fir napisał:
> W dniu sobota, 4 stycznia 2020 09:50:08 UTC+1 użytkownik godek...@gmail.com napisał:
> > W dniu sobota, 4 stycznia 2020 09:26:24 UTC+1 użytkownik slawek napisał:
> > > > Może najpierw pójdź na studia wyższe, a dopiero potem się wypowiadaj.
> > > 
> > > No cóż - wypowiadam się.
> > 
> > Trudno nie zauważyć.
> > Podobnie jak to, że nie masz pojęcia o tematach, na które się wypowiadasz.
> > 
> > > Misiaczku
> > 
> > "Misiaczku" to możesz mówić do kolesi, którym ssiesz pałki na dobranoc.
> > 
> 
> 
> lol, widze ze kolega zerwal ze swoja filozofia by limitowac sie w tekstach (gdy ja pisalem o krowach robiacych na dywan w bibliotece) ;c - w zasadzie to nawet dobrze bo smiesznie sie takie cos czyta (choc to zalezy od szczegolow bo
> czasem mozna tez popasc w depresje)

Chyba po prostu trzeba dostosowywać język do tego, z kim się rozmawia.

> user slawek jest dziwny, wiele lat temu 
> (z 10 pewnie albo i wiecej (?) nie jestem pewien costam pisaywal z sensem

10 lat temu? To ile on miał wtedy lat? 6?

> ostatnio
> cos gorzej mu czasem wychodzi - sam jednak staram sie (czy moze staralbym gdybym tu wiecej pisywac) limitowac w wyrazaniu krytyki bo zauwazylem ze niektorzy przesadnia na nia reaguja

No, ja generalnie też staram się trzymać od takich tematów z daleka.
Teraz... nie wiem, co mnie podkusiło, żeby się wdawać w dyskusję.
 
> (nop kiedys mnie wpieniel user AL z ameryki, ktory costam pisywal z sensem i 
> po skrytykowaniu czegos przeze mnie odszedl z grupy co nie bylo ok bo moim zdaniem bylo przesadna reakcja

Nie sądzę, żeby to była reakcja na jeden post, albo na jednego użytkownika.
On się co chwila naburmuszał i "dodawał kogoś do swojego killfile'a"
(w moim odczuciu zresztą słusznie, bo ludzie odpowiadali mu jakimiś bezdennymi głupotami)

> - z drugiej strony nieststy na odwrot niejacy zasyfiacze i patologiczni oglupiacze rozwalali ta grupe pewnie nie mniej niz lunatyczny przyglup-nudziarz broneq i ciezko bylo czegos nie powiedziec, choc i to niewiele pomagalo,
> 
> smutne zycie, co robic)

Nie wiem.
Pomału rusza polska Quora.
Na razie trochę wieje tam pustkami, ale można niekiedy znaleźć sensownych ludzi, więc zobaczymy, może chwyci.

(Ja w sumie to teraz nie bardzo mam czas na takie rzeczy)

W dniu sobota, 4 stycznia 2020 15:49:00 UTC+1 użytkownik godek...@gmail.com napisał:
> W dniu sobota, 4 stycznia 2020 13:39:52 UTC+1 użytkownik fir napisał:
> > W dniu sobota, 4 stycznia 2020 09:50:08 UTC+1 użytkownik godek...@gmail.com napisał:
> > > W dniu sobota, 4 stycznia 2020 09:26:24 UTC+1 użytkownik slawek napisał:
> > > > > Może najpierw pójdź na studia wyższe, a dopiero potem się wypowiadaj.
> > > > 
> > > > No cóż - wypowiadam się.
> > > 
> > > Trudno nie zauważyć.
> > > Podobnie jak to, że nie masz pojęcia o tematach, na które się wypowiadasz.
> > > 
> > > > Misiaczku
> > > 
> > > "Misiaczku" to możesz mówić do kolesi, którym ssiesz pałki na dobranoc.
> > > 
> > 
> > 
> > lol, widze ze kolega zerwal ze swoja filozofia by limitowac sie w tekstach (gdy ja pisalem o krowach robiacych na dywan w bibliotece) ;c - w zasadzie to nawet dobrze bo smiesznie sie takie cos czyta (choc to zalezy od szczegolow bo
> > czasem mozna tez popasc w depresje)
> 
> Chyba po prostu trzeba dostosowywać język do tego, z kim się rozmawia.
> 
> > user slawek jest dziwny, wiele lat temu 
> > (z 10 pewnie albo i wiecej (?) nie jestem pewien costam pisaywal z sensem
> 
> 10 lat temu? To ile on miał wtedy lat? 6?
> 
> > ostatnio
> > cos gorzej mu czasem wychodzi - sam jednak staram sie (czy moze staralbym gdybym tu wiecej pisywac) limitowac w wyrazaniu krytyki bo zauwazylem ze niektorzy przesadnia na nia reaguja
> 
> No, ja generalnie też staram się trzymać od takich tematów z daleka.
> Teraz... nie wiem, co mnie podkusiło, żeby się wdawać w dyskusję.
>  
> > (nop kiedys mnie wpieniel user AL z ameryki, ktory costam pisywal z sensem i 
> > po skrytykowaniu czegos przeze mnie odszedl z grupy co nie bylo ok bo moim zdaniem bylo przesadna reakcja
> 
> Nie sądzę, żeby to była reakcja na jeden post, albo na jednego użytkownika.
> On się co chwila naburmuszał i "dodawał kogoś do swojego killfile'a"
> (w moim odczuciu zresztą słusznie, bo ludzie odpowiadali mu jakimiś bezdennymi głupotami)
> 

zdaje mi sie ze mogla byc, AL gadal tez glupoty ale czasem tez okazywalo sie ze w niektorych sprawach moje wnioski byly zbierzne z niektorymi jego wnioskami tylko osiagniete inna droga ...

pytanie jaki lewel gruboskornosci jest wskazany na grupie bo kwestia jest taka ze bycie tak gruboskornym i glupawym jak sporo userow napewno nie jest wskazane ale bycie zbyt przewrazliwoionym (przynajmniej w srodowisku ktore jest hruboskurne ) tez nie ma wiele sensu (tj. prowadzi byc moze do gorszych skutkow - (ciezko powiedziec)

odpowiedz na to pytanie jest dosyc ciezka chyba, gruboskornosc jest generalnie mocno absurdalana i pierze mozg, nadwrazliwosc z kolei byc moze daje zbyt duza izloacje i jest malo praktyczna (choc zarazem powoduje pewne oryginalnosc i pewnie odkrywczosc, ale ma to swoja cene)


> > - z drugiej strony nieststy na odwrot niejacy zasyfiacze i patologiczni oglupiacze rozwalali ta grupe pewnie nie mniej niz lunatyczny przyglup-nudziarz broneq i ciezko bylo czegos nie powiedziec, choc i to niewiele pomagalo,
> > 
> > smutne zycie, co robic)
> 
> Nie wiem.
> Pomału rusza polska Quora.
> Na razie trochę wieje tam pustkami, ale można niekiedy znaleźć sensownych ludzi, więc zobaczymy, może chwyci.
> 
> (Ja w sumie to teraz nie bardzo mam czas na takie rzeczy)

fir <profesor.fir@gmail.com> Wrote in message:
> user slawek jest dziwny, wiele lat temu (z 10 pewnie albo i wiecej (?) nie jestem pewien costam pisaywal z sensem 

Więcej. Co do sensu to różnie - czasem z sensem, częściej bez.

>ostatniocos gorzej mu czasem wychodzi - sam jednak staram sie (czy moze staralbym gdybym tu wiecej pisywac) limitowac w wyrazaniu krytyki 

Czasu mniej, w sensie wolnego czasu w ciągu doby i w sensie
 statystycznej dożywalnošci. A i niektórych tematach NDA/RODO
 zabrania pisać.

fir <profesor.fir@gmail.com> Wrote in message:
> (nop kiedys mnie wpieniel user AL z ameryki, ktory costam pisywal z sensem i po skrytykowaniu czegos przeze mnie odszedl z grupy co nie bylo ok bo moim zdaniem bylo przesadna reakcja- z drugiej strony nieststy na odwrot niejacy zasyfiacze i patologiczni oglupiacze rozwalali ta grupe pewnie nie mniej niz lunatyczny przyglup-nudziarz broneq i ciezko bylo czegos nie powiedziec, choc i to niewiele pomagalo,smutne zycie, co robic)

No, kiedyś można było potrollować, dziś wieje nudą, nie ma AL, AK,
 qurczaka, został jeszcze Fir i "romantyczka" - ale to nie to co
 kiedyś. Dawniej wystarczyło rzucić "Atari to syf" i od razu była
 zadyma, dziś młodzi nie wiedzą nawet co to było Atari. Takie
 czasy.

Niemniej jednak: nie znać dziś Pythona to tak jak nie napisać
 programu w Basicu na gumiaka. A gdy Pythona (dynamiczny, kacze
 typowanie, GC, funkcje first class) połączyć z GoF itd. - to
 efekty bywają spektakularne. Choć przyszłość należeć może do
 funkcyjnych - ani Python, ani C/C++/C#/C--, ani tym bardziej
 paszczalopodobne... nie są odpowiednie dla procesorów z setkami
 rdzeni. Trzeba się zająć np. Haskellem and/or Verilogiem. Bo - z
 pewnych cudacznych przyczyn - niektóre rzeczy da się zrobić na
 FPGA znacznie łatwiej niż na MCU.

On Saturday, January 4, 2020 at 7:02:56 PM UTC+1, slawek wrote:
> fir <p.f@gl.c> Wrote in message:
> > (nop kiedys mnie wpieniel user AL z ameryki, ktory costam pisywal z sensem i po skrytykowaniu czegos przeze mnie odszedl z grupy co nie bylo ok bo moim zdaniem bylo przesadna reakcja- z drugiej strony nieststy na odwrot niejacy zasyfiacze i patologiczni oglupiacze rozwalali ta grupe pewnie nie mniej niz lunatyczny przyglup-nudziarz broneq i ciezko bylo czegos nie powiedziec, choc i to niewiele pomagalo,smutne zycie, co robic)
> 
> No, kiedyś można było potrollować, dziś wieje nudą, nie ma AL, AK,
>  qurczaka, został jeszcze Fir i "romantyczka" - ale to nie to co
>  kiedyś. Dawniej wystarczyło rzucić "Atari to syf" i od razu była
>  zadyma, dziś młodzi nie wiedzą nawet co to było Atari. Takie
>  czasy.

No cóż... czas leci i nie jest z gumy, jak go stracę na udział w zadymie, to
nie będę mógł (w tym czasie) pracować nad czym pożytecznym - chyba że kolega
używa słowa 'zadyma' w jakimś konstruktywnym znaczeniu, typu: napierdalamy się
na rzeczowe argumenty żeby uzyskać najlepsze rozwiązanie... Ale to na publicznym
forum też mało możliwe, każdy cenne pomysły, technologie, kanały zbytu, trzyma
dla siebie. 

Pozdrawiam

On Friday, January 3, 2020 at 1:18:08 AM UTC+1, slawek wrote:

> 1. IMO Python jest niezbyt dobry dla programów mających ponad
>  100000 LOC (nie licząc bibliotek i cudzych modułów). Idealnie
>  program w Pythonie to jakieś 2000 do 5000 LOC robiące to do czego
>  w C++ potrzeba byłoby jakiegoś giganta na pół miliona linii kodu.
>  Oczywiście całkiem konkretne rzeczy da się zrobić w np. 50
>  linijkach lub mniej. Przykładowo: zassać dane z bazy, zrobić
>  obliczenia i narysować publish-ready wykresy.


Tam nie ma więcej niż 50 linii kodu:

https://doc.qt.io/qt-5/qtcharts-linechart-example.html
https://doc.qt.io/qt-5/qtcharts-areachart-example.html

W przykładach jest jakby mniej.


Możliwości też sporo:

https://doc.qt.io/qt-5/qtcharts-examples.html


Pozdrawiam